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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This document specifies the architectural requirements for deHvery of consistent IMS services to the user regardless of 
the attached access type (e.g. CS domain access, or IP-CAN). 

Consideration is given to how to access IMS Services (see clause 22.4 of TS 22.101 [9]) while still allowing innovative 
services. 

IMS control of Emergency calls that utilise TS12 are outside the scope of this specification in this release. 

The scope of the specification includes: - 

- Session establishment when using CS access for media transmission for an IMS service 

- Support of Service continuity as specified in TS 23.237 [12] 

- Access domain selection 

- IMS control of services where the media is transported via the CS network (e.g. managing of mid-call services) 

- Service data management 

The solution is applicable for UE"s with or without ICS functionality, and is applicable for the following deployment 
scenarios: 

- An operator who supports for their subscribers only UEs that have ICS functionality 

- An operator who supports for their subscribers only UEs that do not have ICS functionality 

- An operator who supports for their subscribers UEs which do and do not have ICS functionality (to different 
subscribers and the same subscribers) ensuring the coexistence of UEs that have and do not have ICS 
functionality. 

- Inbound roaming subscribers on an operator's network that supports either the same or different ICS 
functionality that the inbound roaming subscriber is using, ensuring the coexistence of UEs that have and do not 
have ICS functionality. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS)". 

[3] 3GPP TS 23.002: "Network architecture". 

[4] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services". 

[5] 3GPP TS 23.003: "Numbering, addressing and identification". 



ETSI 



3GPP TS 23.292 version 8.0.0 Release 8 8 ETSI TS 1 23 292 V8.0.0 (2008-1 1 ) 

[6] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[7] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2". 

[8] 3GPP TS 24.173: "IMS Multimedia Telephony Communication Service and Supplementary 

Services; Stage 3". 

[9] 3GPP TS 22.101: "Services Aspects; Service Principles". 

[10] 3GPP TS 23.221: "Architectural requirements". 

[11] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and Circuit Switched (CS) networks". 

[12] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) service continuity". 

[13] 3GPP TS 24.081: "Line Identification Supplementary Services - Stage 3" 

[14] 3GPP TS 24.082: "Call Forwarding supplementary service; Stage 3". 

[15] 3GPP TS 24.072: "Call Deflection (CS) Supplementary Service; Stage 3". 

[16] 3GPP TS 24.088: "Call Barring (CB) Supplementary Service - Stage 3". 

[17] 3GPP TS 26.1 14: "A IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling 

and interaction" . 

[18] 3GPP TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 3". 

[19] 3GPP TS 24.091: "Explicit Call Transfer (ECT) supplementary service; Stage 3". 

[20] 3GPP TS 24.084: "Multi Party supplementary service - Stage 3". 

[21] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; 

Stage 3". 

[22] 3GPP TS 23.009: "Handover Procedures". 

[23] 3GPP TS 25.413: "UTRAN lu interface Radio Access Network AppHcation Part (RANAP) 

signalling" 

[24] OMA-ERELD-DM-V1_2-20060602-C: "Enabler Release Definition for OMA Device 

Management, Candidate Version 1.2". 

[25] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions". 

[26] 3GPP TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network 

(CN) subsystem Protocol specification" . 

[27] 3GPP2 C.SOOOl-D: "Introduction to cdma2000 Spread Spectrum Systems - Revision D". 

[28] 3GPP TS 24.61 1: "Anonymous Communication Rejection (ACR) and Communication Barring 

(CB); using IP Multimedia (IM) Core Network (CN) subsystem Protocol specification". 

[29] 3GPP TS 24.096: "Name identification supplementary services; Stage 3". 

[30] 3GPP TS 24.010: " Mobile radio interface layer 3 Supplementary services specification; General 

aspects". 



ETSI 



3GPP TS 23.292 version 8.0.0 Release 8 9 ETSI TS 1 23 292 V8.0.0 (2008-1 1 ) 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Access Leg: The call leg between the UE and the SCC AS. 

CS Bearer Control Signalling Path: Signalling path used to control the call established to set up the CS media bearer 
between the UE and IMS. 

ICS UE: An IMS capable UE with additional ICS-specific functionality. 

ICS User: An ICS user is an IMS subscriber that receives communication services centralized in IMS, regardless of the 
attached access type (e.g. CS domain access, or IP-CAN). 

IMS Centralized Services: See definition in TS 22.101 [9]. 

Remote Leg: The call leg formed between the SCC AS and the remote end for presentation of the SIP UA behaviour to 
IMS on behalf of the UE. The TAS, and other Application Servers are invoked on the Remote Leg. 

Service Control Signalling Path: Signalling path established between the UE and the SCC AS, either directly via an 
IP-CAN or via CS network elements for service control signalling. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

ADS Access Domain Selection 

CAA CS Access Adaptation 

CSRN CS domain Routing Number. See TS 23.003 [5] for more information. 

DN Directory Number (e.g. MSISDN) 

ICS IMS CentraHzed Services 

IMRN IP Multimedia Routing Number. See TS 23.003 [5] for more information. 

IN Intelligent Network 

lUA ICS User Agent 

MMTel Multimedia Telephony 

SCC AS Service Centralization and Continuity Application Server 

T-ADS Terminating ADS 

TAS Telephony Application Server 



4 High level principles and requirennents 

4.1 General 

IMS Centralized Services (ICS) provides communication services such that all services, and service control, are based 
on IMS mechanisms and enablers. It enables IMS services when using CS access (e.g. TS 24.008[6], 3GPP2 C.SOOOl-D 
[X]) for the media bearer. 

With ICS, the user services are provided by IMS. User sessions are controlled in IMS via PS or CS access. When using 
a CS access network, or when using a PS access networks that doesn"t support the full duplex speech component of an 
IMS service, the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions. 

If the PS access network does support the full duplex speech component of an IMS service then existing IMS session 
procedures are used as specified in TS 23.228 [2]. 
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ICS provides mechanisms to support the use of CS media bearer for IMS sessions. With ICS, IMS sessions using CS 
media are treated as standard IMS sessions for the purpose of service control and service continuity. 

ICS defines signalling mechanisms between the UE and IMS for transport of information required for service continuity 
when using CS access for media transport. 

4.2 Service consistency 

The following requirement(s) are defined to ensure service consistency. 

- IMS services as defined in clause 22.4 of TS 22.101 [9] shall be consistently provided when using a CS or a PS 
access network for the media of the IMS service subject to the capability of the UE and the access network. 



4.3 Service continuity 



Service continuity shall be provided when underlying mobility results in a change of access network capabilities, e.g. 
support of Gm reference point in conjunction with CS bearer may not be possible after handover from UTRAN to 
GERAN. 

4.4 Session scenarios 

4.4.1 Overview 

4.4.2 ICS UE Session Scenarios 

When an ICS UE accesses IMS services over a CS network, or a PS network which do not support the full duplex 
speech component of an IMS service, the following IMS session scenarios shall be supported according to the 
procedures specified in TS 23.228 [2], along with the solution specified in this document. 

For the following scenarios, video service is only applicable with a device and a network that are capable of video 
application and over the UTRAN access network. 

- Basic voice or voice and video service origination and terminating sessions. 

- Voice or voice and video origination and termination service sessions with Line ID services (e.g. OIP, OIR, TIP, 
TIR) controlled in IMS. 

Voice or voice and video origination and termination service sessions with Communication Barring services 
controlled in IMS. 

Voice or voice and video termination service sessions with Communication Diversion services controlled in MS. 

- Voice or voice and video origination and termination service sessions with mid-call services (e.g. Hold/Resume, 
Conferencing, CW, ECT) controlled in IMS. 

- Communication services setting modifications (e.g., changing forwarding info or activating barring services, 
etc). 

- The solution shall provide generic capabilities to enable introduction of new IMS services utilizing CS bearers 
without further standardisation. 

- Adding/removing a real time video media over CS access to/from an existing session (see TS 22.173 [4]). 

4.5 Service settings data management 

An ICS UE supporting multimedia telephony shall manage the IMS multimedia telephony communication service 
settings data as specified in TS 24.173 [8]. 
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For a UE not supporting multimedia telephony, the MSC Server enhanced for ICS may implement a communication 
service setting conversion function between CS signalling (e.g., as described in TS 24.010 [30]) and communication 
service setting procedures (e.g. as defined in TS 24.173 [8]). 

NOTE: A downloadable application can enable a UE not supporting multimedia telephony to perform service 
data management. 

4.6 Identities 

4.6.1 Identities used by an ICS UE 

4.6.2 Identities used by an MSC Server enhanced for ICS 

The MSC Server enhanced for ICS shall use a Private User Identity and Public User Identity specifically reserved for 
IMS registrations from an MSC Server. This is to avoid conflicts in IMS registration by a UE and an MSC Server 
registering on behalf of the same subscriber. The identities reserved for ICS identities are defined in TS 23.003 [5]. 

Similar to the temporary Public User Identity used when there is no ISIM present (see clause 13.4 of TS 23.003 [5]), the 
ICS specific Public User Identity shall be prohibited from being used to originate sessions and shall be prohibited from 
being used to identify a terminating subscriber for incoming sessions. 

An MSC Server shall use only those Public User Identities representing E.164 numbers from the subscriber's IMS 
profile to originate and terminate calls. 

NOTE: The subscriber's IMS profile will need to be provisioned with the DNs (e.g. MSISDN) in the subscriber's 
CS profile associated with speech/audio (e.g. TSll), if seamless service between IMS and the CS domain 
is to be provided. 

4.7 Coexistence of an ICS UE and a non ICS UE 

It shall be possible to provide ICS for an ICS UE and a non ICS UE in home and in visited networks. 

Home and visited networks with an MSC Server enhanced for support of ICS shall support call originations and 
terminations for ICS UE. 

The MSC Server enhanced for ICS avoids conflicts with other IMS registrations (which includes that used by an ICS 
UE) by using a Private User Identity and Public User Identity specifically reserved for use by MSC Server registrations. 
See clause 4.6.2 for more information. An IMS operator who provides services for its subscribers, using both ICS UE"s 
and MSC Servers enhanced for ICS needs to make the following provisions in order to avoid registration conflicts: 

- Configure the ICS specific Private User Identity, as defined in clause 4.6.2 to point to the subscriber's implicit 
registration set; and 

- Add the ICS specific Public User Identity, as defined in clause 4.6.2 to the subscriber's implicit registration set. 

4.8 Routing of originated calls to IMS 

When the ICS UE establishes the Service Control Signalling Path over II or Gm prior to the CS Bearer Control 
Signalling Path, the ICS UE shall use the routing number provided by the network in response to service control 
signalling as the B-Party number for establishing the CS Bearer Control Signalling Path. 
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Architecture model and reference points 



5.1 



Overview 



ICS enables IMS services when using CS access for media transport. Users are provided with a consistent experience of 
services. 

When using PS access networks which support the full duplex speech media component of an IMS service, procedures 
defined in TS 23.228 [2] are used for to provide IMS services with enhancements as identified in this document. 

For other access networks, media established via the CS domain is used in conjunction with IMS service control. When 
using a UE that has been enhanced for ICS, IMS service control is enabled by a transparent control channel (the Service 
Control Signalling Path) between the UE and IMS. When using a UE which has not been enhanced for ICS, IMS 
service control can be enabled by an MSC Server enhanced for ICS. 

For systems with a CS domain access based on TS 24.008 [6], CAMEL shall be used for implementing the IN triggers. 



5.2 



Reference architecture 



Figure 5.2-1 provides the reference architecture for IMS sessions established using CS bearers. 



^ 

^ 



II 



sec AS 



ISC 



Gm 



CSCF 



CS Access 



A/Iu 



12 
MSC Server 



Mc 



CS-MGW 



Figure 5.2-1 : ICS Reference Architecture 

The architecture introduces the following: 

The sec AS, which provides functions specific to IMS Centralized Services. 

- Enhancements to the MSC Server for ICS. 

- Enhancements to the UE for ICS 

Not all of the above are required in a network implementing ICS. 



ETSI 



3GPP TS 23.292 version 8.0.0 Release 8 1 3 ETSI TS 1 23 292 V8.0.0 (2008-1 1 ) 

5.3 Functional Entities 

5.3.1 sec AS 

The sec AS is a home network based IMS AppHcation that provides functionahty required to enable IMS CentraHzed 
Services. The SCC AS is inserted in the session path using originating and terminating iFCs; it is configured as the first 
AS in the originating iFC and as the last AS in the terminating iFC chain. The SCC AS may also be invoked through the 
use of PSI termination procedures when using CS access. 

The SCC AS implements one or more of the following functionalities: 

- ICS User Agent (lUA): The ICS User Agent (lUA) function provides SIP UA behaviour on behalf of the UE 
for setup and control of for IMS sessions using CS bearers that are established with or without the use of Gm or 
II between the UE and the SCC AS For sessions established using Gm or II between the ICS UE and the SCC 
AS the lUA combines the service control signalling with the description of the bearer, e.g. SDP, established via 
the CS access to present a standard IMS session on behalf of the UE. 

- CS Access Adaptation (CAA): The CS Access Adaptation (CAA) is an adaptation function for the service 
control signalling communicated transparently via the CS domain between the UE and the SCC ASThe CAA 
processes the service control signalling received via the CS access for interworking with other IMS functional 
elements. The CAA is only used when using the CS network for communication of service control signalling. 

- Terminating Access Domain Selection (T-ADS): Terminating Access Domain Selection (T-ADS) provides: 

- Directs an incoming session to an ICS User; 

- Influences the selection of a contact amongst registered contacts for the ICS User; 

- Influences the selection of an access network for delivery of the incoming session to the selected contact; 

- Performs breakout to the CS Domain by fetching the CSRN. 

T-ADS shall take into account the access network and UE capabilities, IMS registration status, CS status, existing 
active sessions, and operator policies and user preferences. 

For delivery of an incoming session to an ICS User, the T-ADS shall perform the following: 

1. Assists in delivery of an incoming session, whether to: 

- Deliver all media via PS. 

- Deliver speech/video media via CS and use Gm for service control. 

- Deliver speech/video media via CS and use II for service control. 
Deliver speech/video media via MSC Server enhanced for ICS. 

- Deliver speech/video media via standard MSC Server. 

2. Based on the decision in step 1, it assists in selection of an access network for delivery of the incoming session 
to the ICS User contact address. Selection criteria as specified in TS 23.221 [10] clause 7.2b, Access Domain 
Selection for terminating sessions are used for access network selection. 

3. For delivery of incoming sessions to the UE registered in CS domain via standard MSC Server, it fetches the 
CSRN for breakout to the CS domain. 

Additionally, when using Gm reference point, T-ADS for ICS UE sessions may be executed in the ICS UE in 
conjunction with the network, based on operator policy and taking into account its own capabilities and those of the 
access network. 

5.3.2 UE enhanced for ICS 

The ICS UE is an IMS UE enhanced with ICS capability. The ICS UE provides the following functions: 
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- Communicates with the SCC AS for service control signaling. 

- Establishes the Bearer Control Signaling Path to setup the media through the CS domain. 

- Executes ADS for originating sessions as specified in TS 23.221 [10] clause 7.2a. 
Assists the SCC AS in the execution of T-ADS if Gm is used. 

The ICS UE uses the Gm reference point when using the PS network for session control signaling. 

5.3.3 MSC Server enhancements for ICS 

The MSC Server (e.g. as described in TS 23.002 [3]) may be enhanced for the support of ICS. 

In addition to the standard MSC Server behavior, an MSC Server which has been enhanced for ICS provides the 
following for an identified ICS user: - 

- It processes the user-network signaling received over the CS access (e.g. A/Iu and E interface) for interworking 
with IMS SIP and vice versa. 

- It controls the MGW functions described in TS 23.002 [3] to enable the interworking between CS access and 
RTP bearers. 

- It performs the interworking to support multimedia call in ICS. 

For subscribers not identified as ICS users, the MSC Server functionality is unchanged. 
MSC Server enhancements for ICS are not required for the support of an ICS UE. 



5.4 Reference points 



5.4.1 Reference Point UE - SCC AS (11) 

The II reference point is used between the UE and the SCC AS for session control signalling over CS access. 
The II reference point performs the following functions: 

- optional session set up via CS access for mobile originating and terminating sessions; 

- optional signalling for additional IMS parameter exchange during session setup; 

- IMS services control via CS access. 

For systems with CS domain access based on TS 24.008[6], the II reference point shall be implemented using USSD 
transport via CS network elements. 

5.4.2 Reference Point MSC Server - CSCF (12) 

The 12 reference point shall be used to route session control signalling between the MSC Server enhanced for ICS and 
the home IMS. The Mw reference point specified in TS 23.228 [2] together with ICS specific extensions shall be used 
over the 12 reference point. 

5.4.3 Reference Point IVISC server - CS-IVIGW (IVIc) 

The Mc reference point, as defined in TS 23.002 [3], is established between the MSC Server enhanced for ICS and the 
CS-MGW. 
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6 Functional description 

6.1 Common IMS Functions 

6.1.1 P-CSCF procedures 

If CS media is present as part of the SIP/SDP message, the P-CSCF shall not use this information when allocating 
resources for the media. 

6.1 .2 IMS ALG procedures 

If CS media is present as part of the SIP/SDP message, the IMS ALG shall not use this information for media related 
functions such as IP address translation. 

6.1.3 S-CSCF procedures 

If CS media is present as part of the SIP/SDP message, the S-CSCF shall allow such media to be used for the service. 



6.1.4 IBCF procedures 



If CS media is present as part of the SIP/SDP message, the IBCF used in roaming scenarios shall not allocate resources 
for the media. The IBCF shall take CS media into account in other media control related functions. 



7 Procedures and flows 

7.1 Signalling and bearer paths 

7.1 .1 Sessions established using the Gm or II reference point 

A Service Control Signalling Path is used to transport service control signalling between the ICS UE and the SCC AS, 
for enabling IMS services when using CS or PS access. The Service Control Signalling Path is used when needed, e.g. 
on session establishment and/or service control of IMS sessions using CS voice bearers. 

For ICS UE sessions, the SCC AS combines the service control signalling received over the Service Control Signalling 
Path with the description of the bearer established via the CS network to present an IMS session on behalf of the UE. 
The service control signalling elements from Gm / II such as A party address shall be used together with the bearer 
description signalling received via CS bearer control signalling path to construct the signalling for the remote leg. 

The Service Control Signalling Path is established via the PS or CS network. 

Figure 7.1.1-1 illustrates how signalling and bearer paths established by the ICS UE are combined at the SCC AS when 
the Service Control Signalling Path is established via the PS network. 
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Service Control Signalling Path via IP-CAN 



CS Bearer Control Signalling Path via CS network 
Media via CS & IMS network 




AS 



CSCF 



ICSUE 



Figure 7.1.1-1 : ICS UE session signalling and bearer path using PS network for Service Control 

Signalling Path 

Upon session initiation, the ICS UE or the SCC AS estabHshes the Service Control Signalling Path for communication 
of service control signalling via the PS network using the Gm reference point. 

The ICS UE also sets up the CS Bearer Control Signalling Path using standard CS network procedures to establish the 
circuit media. 

The SCC AS combines the service control signalling received over the Service Control Signalling Path with the 
description of the bearer established using the CS Bearer Control Signalling Path by acting as a B2BUA as below: 

- Access Leg: The Access Leg is formed with a combination of the Service Control Signalling Path and the CS 
Bearer Control Signalling Path. 

- Remote Leg: The Remote Leg is presented by the SCC AS to the CSCF as an IMS session using IMS SIP 
signalling on behalf of the UE. 

The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at 
the CSCF. 

The SIP UA at the UE maintains the SIP/SDP state machine with the SCC AS also maintaining a copy of the state data. 

Figure 7.L1-2 illustrates how signalling and bearer paths established by the UE are combined at the SCC AS when the 
Service Control Signalling Path is established via the CS network. 



Service Control Signalling Path via CS network 



CS Bearer Control Signalling Path via CS network 



Media via CS & IMS network 




ICSUE 

Figure 7.1.1-2: ICS UE session signalling and bearer path using CS network for Service Control 

Signalling Path 

Upon session initiation, the ICS UE or the SCC AS establishes the Service Control Signalling Path for communication 
of service control signalling via the CS network using the II reference point. In parallel, the ICS UE or the SCC AS sets 
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up the CS Bearer Control Signalling Path using standard CS network procedures to establish the circuit media. The SCC 
AS combines the Service Control Signalling Path with the bearer established using the CS Bearer Control Signalling 
Path by acting as a B2BUA as described above for the case of Service Control Signalling Path established via the PS 
network. 

7.1 .2 Sessions established using CS call control and MSC Server 

Figure 7.1.2-1 illustrates signalling and bearer paths for sessions which are established using standard CS call control 
procedures and MSC Server . 



CS Bearer Control Signalling Path via CS network 



Media via CS & IMS network 




UE 



Figure 7.1.2-1: Session signalling and bearer path using OS call control 

Upon session initiation, the UE or the remote end sets up a call and the call is directed to IMS using standard CS 
procedures; IN (e.g. CAMEL) triggers are used to redirect CS originated calls to IMS. The SCC AS acts a B2BUA for 
presentation of the UA behaviour on behalf of the UE to IMS. 

The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at 
the CSCF. 



7.2 Registration 

7.2.1 IMS registration via CS access 



7.2.1.1 



Overview 



The UE may register (attach) in the CS domain whenever in CS coverage. The existing mobility management 
mechanisms are used in the UE and the CS network. 

After performing a successful location area update procedure to the UE, the MSC Server receives subscriber data from 
the HSS/HLR. This subscriber data may include an optional flag. 

An MSC Server will ignore the flag and continue normal CS operation. An MSC Server that is enhanced for ICS shall 
perform the following: 

- If the flag is received and is supported by the MSC Server, then the MSC Server shall analyse the value of the 
flag as follows: 

- If the flag is set to true, the MSC Server shall attempt the IMS registration using the 12 reference point. 

- If the flag is set to false, the MSC Server shall not attempt the IMS registration. 

- If the flag is not received or is not supported, the MSC Server may perform some pre-screening (e.g. IMSI range 
analysis) based on operator-policy in order to determine whether or not to attempt IMS registration for this 
subscriber. 
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NOTE 1: Exact pre-screening procedures are operator specific. 

When attempting initial IMS registration on behalf of the ICS User, the MSC Server shall derive a home IMS domain 
name using the identity of the subscriber (e.g. IMSI). This domain name identifies the node (e.g. I-CSCF or IBCF) to 
which the MSC Server shall send the IMS registration. The MSC Server shall also derive IMS user identities required 
for the registration from this identity. The MSC Server shall derive these identities in a manner that prevents collisions 
with other identities automatically derived from the same subscriber identity e.g. from the IMSI by UEs with no ISIM 
as described in TS 23.003 [5]. 

For systems with a CS domain access based on TS 24.008 [6], the subscriber identity used and its derivation is described 
in TS 23.003 [5]. 

The MSC Server then initiates a registration on behalf of the ICS User towards the home IMS indicating support for 
GRUU and including an InstancelD. If a GRUU is received, the MSC Server shall store it. 

NOTE 2: IMS authorization of registrations from a MSC Server enhanced for ICS is outside the scope of this 
specification. 

The routing of the registration messaging is performed by standard IMS routing procedures. Filter criteria shall instruct 
the S-CSCF to perform 3rd party registration towards the SCC AS. 

If IMS registration is successful, then subsequent IMS sessions described in clause 4.4.2 shall be supported in IMS 
using the MSC Server procedures described in this specification. 

The success or failure of the IMS registration shall not impact the CS attach status of the UE. 

The MSC Server enhanced for ICS shall initiate IMS re-registration as necessary to maintain an active IMS registration 
during the period of time in which the UE is attached to the CS domain. 

After successful initial IMS registration, the MSC Server enhanced for ICS shall subscribe to the registration event 
package described in TS 23.228 [2] on behalf of the ICS User. The MSC Server shall use the default public user identity 
received during initial IMS registration for subscription to this package. The MSC Server enhanced for ICS shall refresh 
this subscription as necessary during the period of time in which its IMS registration on behalf of the ICS User is active. 

The MSC Server enhanced for ICS shall initiate IMS deregistration on behalf of the ICS User upon receipt of any 
indication that the UE is no longer considered active at this MSC Server (e.g. Location Cancellation procedure. Purge 
MS procedure, etc.). Per operator policy, the MSC Server enhanced for ICS shall also initiate IMS re-registrations to 
obtain additional temporary- GRUUs as need. 

Upon receipt of a network-initiated deregistration from the IMS, the MSC Server enhanced for ICS shall remove all 
registration details relating to the public user identities contained in the deregistration. Network-initiated deregistration 
from IMS shall not impact the UE"s CS registration status. 

7.2.1 .2 Registration using 12 reference point 

Figure 7.2.1.2-1 describes how IMS registration is performed by the MSC Server enhanced for ICS upon CS attach. 
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UE 



MSC Server 



l-CSCF 



HSS/HLR 



S-CSCF 



sec AS 



1 . CS Attach 



2. CS Location Update, Authentication and obtain Subscriber Data 



3. CS Attach Accept 



4. IIVIS Registration 
Decision 



5. IIVIS Address Discovery 



6. REGISTER 



7. Cx-Query + Cx-Select- 
Pull / Resp 



8. REGISTER 



9. Cx-Put + Cx-Pull / Resp 



10. REGISTER 



1 1 . Completion of Registration Signaling 



Figure 7.2.1.2-1 : Initial IMS Registration via CS Access 

1. The UE initiates standard CS Attach procedures toward the CS network. 

2. The CS network performs standard CS location update, authentication and obtains subscriber data . 

3. A CS Attach Accept is returned to the UE. 

4. The MSC Server decides to initiate IMS registration for this subscriber. 

5. The MSC Server derives a domain name from the subscriber" s identity (e.g. IMSI) and discovers the address of 
the appropriate I-CSCF/IBCF. 

6. The MSC Server sends a SIP REGISTER to the IMS with a private and temporary pubHc user identity derived 
from the subscriber" s IMSI as well as an InstancelD. The REGISTER also contains information indicating the 
capabilities and characteristics of the MSC Server as a SIP User Agent Client. The I-CSCF verifies that the 
incoming REGISTER origins from a trusted MSC server (in the same way it would check that a normal 
REGISTER origins from a trusted P-CSCF). 

7. The I-CSCF initiates standard procedures for S-CSCF location/allocation. 

8. The I-CSCF forwards the REGISTER to the S-CSCF. 

9. The S-CSCF identifies the REGISTER as being from the MSC Server. The S-CSCF skips any further 
authentication procedures and performs registration procedures with the HSS. 

10. The S-CSCF performs standard service control execution procedures. Filter criteria directs the S-CSCF to send a 
REGISTER to the SCC AS. 

1 1 . IMS registration procedures are completed. 



7.2.1.3 



Deregistration using 12 reference point 



Figure 7.2.1.3-1 describes how IMS deregistration is performed by the MSC Server enhanced for ICS upon detection of 
the Location Cancellation procedure. Identical IMS deregistration procedures would be initiated by the MSC Server 
enhanced for ICS upon receipt of any other indication that the UE is no longer considered active at this MSCA^LR. 
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UE 



VMSC MSC Server (old) l-CSCF 



HSS/HLR 



S-CSCF sec AS 



1. Location Updating 



2. CS Location Update and Autlientication procedures 



3. Cancel Location 



4. De-REGISTER 



5. Cx-Query + Cx-Select-Pull / 
Resp 



6. De-REGISTER 



7. Cx-Put + Cx-Pull / Resp 

-4 ► 



8. De-REGISTER 



9. Completion of De-registration Signaling 



Figure 7.2.1.3-1 : IMS Deregistration via CS Access 

1. The UE initiates standard location updating procedures toward the CS network. 

2. The CS network performs standard CS location updating and authentication procedures. 

3. The HSS initiates location cancellation procedures towards the old VLR. 

4. The MSC Server initiates IMS deregistration for this subscriber by sending a SIP REGISTER with an expiration 
time of zero seconds. 

5. The I-CSCF initiates standard procedures for S-CSCF location/allocation. 

6. The I-CSCF forwards the REGISTER to the S-CSCF. 

7. The S-CSCF identifies the REGISTER as being from the MSC Server which is a trusted network node. The S- 
CSCF skips any further authentication procedures and performs deregistration procedures with the HSS. 

8. The S-CSCF performs standard service control execution procedures. Filter criteria directs the S-CSCF to send a 
REGISTER to the SCC AS. 

9. IMS deregistration procedures are completed. 

7.2.2 IMS Registration via IP-CAN 

Whenever the ICS UE acquires IP connectivity via an IP-CAN, the UE shall register in the IMS if not already registered 
in IMS. Registration with IMS is in accordance with the procedure as defined in TS 23.228 [2]. 

The filter criteria shall contain a condition that a 3rd-party registration should be performed by the S-CSCF via the ISC 
interface towards the SCC AS. This supports ADS functionality in the SCC AS. 

1. The UE registers in the IMS as described in clause 5.2.2.3 of TS 23.228 [2] indicating its abilities to use ICS.. 
NOTE: Access networks capabilities could be taken into account when sending any indications. 

2. The S-CSCF informs the SCC AS about the registration, using the procedures defined in clause 6.3 of 
TS 23.218 [7]. 

IMS registration via IP-CAN is performed independently of the UE's CS state. 

Information regarding home network support of ICS shall be configured in the ICS UE, e.g. via OMA DM [24]. 
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7.3 



Originations 



7.3.1 Originating sessions using PS media 

When the ICS UE has access to a PS network that supports the full duplex speech component of the an IMS service, 
originating IMS procedures (as described in clause 5.6 of TS 23.228[2]) shall be used to set up the session. The S-CSCF 
shall insert the SCC AS in the IMS session path using originating initial filter criteria. The SCC AS shall be the first AS 
inserted into the session path. 

7.3.2 Originating sessions using CS media 



7.3.2.1 



Non ICS UE originating sessions using CS media 



7.3.2.1.1 



Overview 



Originating sessions using CS media made by non ICS UEs that have been successfully registered in IMS by the MSC 
Server can utilize IMS session control. The non ICS UE initiates a standard CS originating session toward the MSC 
Server enhanced for ICS, which in turn can initiate an IMS originating session using the 12 reference point. 

For these sessions, the MSC Server shall perform interworking between the 12 reference point and CS signalling (e.g. as 
described in TS 24.008 [6]). The MSC Server shall also control a CS-MGW using the Mc reference point to perform 
interworking between CS access bearers and RTP bearers on the Mb reference point. 

The SCC AS shall be inserted in the IMS session path using the iFC. 



7.3.2.1.2 



Origination using 12 reference point 



Figure 7.3.2.1.2-1 describes how IMS originations are performed via CS access for non ICS UE. 

non ICS UE A MSC Server MGW l/S-CSCF SCC AS 



1. CS call setup (B) 



2. INVITE (B, SDP from IMS-MGW) 



3. INVITE (B, SDP from IMS-MGW) 



4. INVITE (B, SDP from IMS-MGW) 



5. INVITE (B, SDP from IMS-MGW) 



6. Completion of Session Setup Procedures 



CS domain bearer 



IMS bearer 



UEB 



Figure 7.3.2.1.2-1: IMS Origination via CS Access for non ICS UE 

1. The non ICS UE A sends a CS call setup message containing the B-party number to the MSC Server enhanced 
for ICS according to standard CS originating procedures. 

2. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the B-party number. If a GRUU 
is to be included as described in TS 23.228 [2], then a temporary-GRUU is included as the contact address if 
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privacy has been requested or a public-GRUU if privacy has not been requested. The INVITE also contains SDP 
received from the CS-MGW. 

3. The S-CSCF performs standard service control execution procedures. Filter criteria direct the S-CSCF to send 
the INVITE to the SCC AS. 

4. The INVITE is sent to the S-CSCF. 

5. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B- 
party. 

6. Completion of the session and bearer control setup procedures. 



7.3.2.1.3 



Origination when using an IVISC Server 



Figure 7.3.2.1.3-1 describes how IMS originations are performed via CS access for non ICS UE attached to a legacy 
MSC or MSC-Server which has not been enhanced for ICS. 



Non ICS UE MSC-Server MGCF 



1. 03 call setup 



(B Party DN) 



2. Fetch IMRN 



3. lAM(IMRN) 



CSCF 



INVITE(IMRN ) 



SCC AS 



INVITE(IMRN ) 



6. 03 Origination 
Processing 



7. INVITE 



(B-Party DN) 



8. Completion of 

session setup 

procedures 



Figure 7.3.2.1.3-1: IMS Origination via CS Access for non ICS UE 

1. The non ICS UE originates a call in the CS domain to party-B according to standard origination procedures. 

2. IN (e.g. CAMEL) origination triggers are used at the MSC-Server for fetching an IP Multimedia Routing 
Number (IMRN) that is used to route the request to IMS. 

3. The MSC-Server routes the call towards the user's home IMS network using the IMRN via an MGCF. 

4. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating ICS user. 
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5. The I-CSCF routes the INVITE based on one of the following standard procedures specified in "PSI based 
Application Server termination - direct and PSI based Application Server termination - indirect" procedures in 
TS 23.228 [2] either directly to the SCC AS or via the S-CSCF. 

6. When the INVITE arrives at the SCC AS, the original called number and the calling party number are used to 
setup the outgoing call leg to party-B in accordance with the AS origination procedure defined in clause 5.6.5 of 
TS 23.228 [2]. 

NOTE: The method for discovery of original called number and calling party number at the SCC AS if ISUP 
does not provide this information is implementation dependant. This can be realized by interactions between the 
SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this specification. 

7./8. The SCC AS sends the INVITE back to the S-CSCF for completion of the call toward the remote end. 

7.3.2.2 ICS UE Originating sessions using CS media 

7.3.2.2.1 Overview 

IMS session control is used for ICS UE originated sessions established with use of CS media bearer. 

When using the Gm reference point, the ICS UE initiates a standard IMS originating session indicating use of CS media 
bearer for the session. The SCC AS is inserted in the IMS session path using originating iFC. The ICS UE also sets up a 
standard CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer. The session 
control signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS 
originating session to the S-CSCF over the Remote Leg. 

The ICS UE should be able to detect an emergency session establishment request. If the ICS UE using a CS access 
detects the request for the establishment of an emergency session, the ICS UE shall attempt to initiate a CS emergency 
call. 

If the ICS UE could not detect an emergency call and originates the session with CS media using Gm reference point, it 
will forward an IMS session establishment request to the P-CSCF. If the P-CSCF detects such an emergency call, it 
rejects the request with an indication that this is for an emergency session as described in TS 23.167[25]. 

NOTE: If the P-CSCF is not ICS aware, it is assumed that some other node in the emergency session path will 
detect the unsupported media and reject it or the call will be delivered to the PSAP without voice media 
component. Normal error handling applies in this case. 

As described in TS 23. 167 [5] an ICS UE that initiated a non UE detectable emergency session will receive an indication 
in responses from which it can deduce that the session is for emergency. Upon receiving an emergency session rejection 
or session rejection with this indication, the ICS UE shall fall back to CS according to TS 23.167[25]. 

When not using the Gm reference point, the following apply: 

- For sessions originated using a B party" s SIP URI (not using user = phone), the ICS UE initiates a dialogue with 
the SCC AS over the II reference point indicating session origination. The ICS UE also sets up a CS originated 
session addressing a PSI DN associated with the SCC AS to establish the CS bearer. The session control 
signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS 
originating session to the S-CSCF over the Remote Leg. 

- For all other cases, the ICS UE initiates a standard CS originating call using B party" s E.164 number. The call is 
routed to IMS via a standard MSC Server using IN (e.g. CAMEL) based redirection or an MSC Server enhanced 
with ICS. If the B party number is detected by the MSC Server as an emergency number then it will be handled 
as per existing MSC Server call handling procedures. Additionally, the ICS UE may use the II reference point 
for communication of additional parameters. 

For video call originations, the following apply for the ICS UE and the networks supporting the CS video functionality 
for ICS: 

- When the ICS UE is attached to an MSC Server enhanced for ICS, after the multimedia connection is 
established, the MSC Server enhanced for ICS shall perform the H.245 negotiation to set up the video media 
bearer based upon the procedures defined in TS 29.163 [11]; 
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- When the ICS UE is attached to an MSC Server , the MGCF/IMS-MGW shall perform the H.245 negotiation 
procedure as specified in TS 29.163 [11]. 

The following clauses show pairs of flows, one for an ICS UE when using an MSC Server and the other for an MSC 
Server enhanced for ICS. They are for the most part identical except that in the case of an MSC Server enhanced for 
ICS the INVITE towards the SCC AS is sent directly from the MSC Server whereas an MSC Server sends an ISUP 
lAM and the MGCF interworks this to an INVITE towards the SCC AS. 



7.3.2.2.2 



Originations with CS media when using 11 



7.3.2.2.2.1 



Originations to a SIP URI 



Figure 7.3.2.2.2.1-1 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to 
address the called party and when the ICS UE is attached to an MSC Server enhanced for ICS and the user is identified 
as an ICS user. 
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Figure 7.3.2.2.2.1-1 : ICS UE Origination with CS media addressing a SIP-URI when using an MSC 

Server enhanced for ICS 

NOTE 1: 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the CS 
Bearer Control Signalling Path. 

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the II reference point containing 
the UE B address. 

2. The CS Access Adaptation (CAA) function of the SCC AS performs the necessary adaptation of the signalling 
received over the II reference point. The lUA of the SCC AS may allocate a PSI DN and send it to the ICS UE 
A (dynamic SCC AS PSI DN allocation). 
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NOTE 2: Alternate procedures for delivery of the SCC AS PSI DN to the UE are also possible; e.g., the SCC AS 
PSI DN may be provided to the UE during network registration or may be statically configured for the 
UE. In this case, step 3 is skipped. 

3. The SCC AS sends the SCC AS PSI DN to the UE over the II reference point. 

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the 
lUA of the SCC AS by sending a SETUP message to the MSC Server containing the SCC AS PSI DN. 

5. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

6. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to 
be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has 
been requested or public-GRUU if privacy has not been requested. 

7. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC 
AS. The SCC AS is the first AS inserted in the session path. 

8. The lUA of the SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for 
presentation of an IMS session towards the B -party on behalf of ICS UE A. The lUA correlates the CS bearer 
control signalling session with the service control signalling session using the SCC AS PSI and creates a SIP 
INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice media. The 
INVITE request is routed from the SCC AS to the S-CSCF. 

9. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B- 
party. 

10. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. 

For video call, in Step 10, handling of video calls as specified in clause 7.3.2.2.1 Overview apply. 

Figure 7.3.2.2.2.1-2 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to 
address the called party and when the ICS UE is attached to an MSC Server. 
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Figure 7.3.2.2.2.1-2: ICS UE Origination with CS media addressing a SIP-URI when using an MSC 

Server 

NOTE 3: Steps 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the 
setup of the Service Control Signalling Path. 

Steps 1-5 in Figure 7.3.2.2.2.1-2 are identical to steps 1-5 in Figure 7.3.2.2.2.1-1. 

At Steps 6 and 7, the MSC Server sends the lAM using the SCC AS PSI DN to an MGCF which is subsequently inter- 
worked to an INVITE. 

Steps 8-11 in Figure 7.3.2.2.2.1-2 are identical to steps 7-10 in Figure 7.3.2.2.2.1-1. 

For video call, in Step 11, handling of video calls as specified in Clause 7.3.2.2.1 Overview apply. 



7.3.2.2.2.2 



Originations to a B-party number other than SIP-URI 



Figure 7.3.2.2.2.2-1 provides an example flow for a session origination by an ICS UE where the II reference point is 
used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone, and when the ICS UE is 
attached to an MSC Server enhanced for ICS and the user is identified as an ICS user. 
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Figure 7.3.2.2.2.2-1: ICS UE Origination with CS media using a E.164 number, Tel-URI or SIP-URI 

user=phone and an MSC Server enhanced for ICS 

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the II reference point containing 
the UE B address. The ICS UE A also indicates in the II message that an SCC AS PSI DN is not needed for this 
session. 

2. The CS Access Adaptation (CAA) function of the SCC AS performs the necessary adaptation of the signalling 
received over the II reference point. The SCC AS notes the SCC AS PSI DN is not used for this session. 

3. The SCC AS returns an ICS Call Initiation Result to ICS UE A over the II reference point. 

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the 
lUA of the SCC AS by sending a SETUP message to the MSC Server containing the B -party-number. If the B 
party number is detected by the MSC Server as an emergency number then it will be handled as per existing 
MSC Server call handling procedures. 

When the user dials a Non-UE detectable Emergency DN or Emergency URI but II has been established, or if 
the CS origination fails to be routed into IMS, a timer running at the SCC AS will expire as the CS Bearer 
Control Signalling Path was not established towards the SCC AS and an appropriate indication is returned to the 
UE The UE shall not release the CS bearer on receipt of this indication and the UE shall not use the Service 
Control Signalling Path further for the call.. 

5. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

6. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the B-party number. If a GRUU 
is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy 
has been requested or public-GRUU if privacy has not been requested. 

7. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC 
AS. 
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8. The lUA of the SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for 
presentation of an IMS session towards the B -party on behalf of ICS UE A. The lUA correlates the CS bearer 
control signalling session with the service control signalling session and creates a SIP INVITE containing the 
SDP received in the CS Bearer Control Signalling Path, indicating CS voice media and routes the INVITE 
request to the S-CSCF. 

9. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B- 
party. 

10. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. 

For video call, in Step 10, handling of video calls as specified in clause 7.3.2.2.1 Overview apply. 

Figure 7.3.2.2.2.2-2 provides an example flow for a session origination by an ICS UE where the II reference point is 
used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone and when the ICS UE is 
attached to an MSC Server. 
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Figure 7.3.2.2.2.2-2: ICS UE Origination witli CS media using a E.164 number, Tel-URI or SIP-URI 

user=phone and an MSC Server 

NOTE 1: Steps 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the 
setup of the Service Control Signalling Path. 

Steps 1-5 in Figure 7.3.2.2.2.2-2 are identical to steps 1-5 in Figure 7.3.2.2.2.2-1. 

In Steps 6 and 7, IN (e.g. CAMEL) origination triggers are used at the MSC Server for fetching of an IP Multimedia 
Routing Number (IMRN). The MSC Server sends an I AM to an MGCF using the IMRN which is subsequently inter- 
worked to an INVITE. 

In Step 8, the S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the 
SCC AS. This step is skipped if the I-CSCF routes the INVITE request directly to the SCC AS. 

Steps 9-11 in Figure 7.3.2.2.2.2-2 are identical to steps 8-10 in Figure 7.3.2.2.2.2-1. 
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NOTE 2: The method for discovery of original called number and calling party number at the SCC AS if ISUP does 
not provide this information is implementation dependant. This can be realized by interactions between 
the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this 
specification. 

For video call, in Step 11, handling of video calls as specified in clause 7.3.2.2.1 Overview apply.. 



7.3.2.2.3 



Originations with CS media when not using 11 



This procedure may be used when the ICS User dials an E.164 number, a Tel URI or a SIP-URI user=phone, and the 
exchange of additional SIP parameters is not required. The ICS UE initiates a standard CS originating using the B- 
party"s E.164 number or a number derived from the Tel-URL The call is routed to IMS via an MSC Server which is 
enhanced to support ICS or a standard MSC Server using IN (e.g. CAMEL) based re-direction. 

Figure 7.3.2.2.3-1 provides an example flow for a session origination by an ICS UE where the II reference point is not 
required to set up the session and a MSC Server enhanced for ICS is used to set-up the CS Bearer Control Signalling 
Path and the user is identified as an ICS user.. 
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IMS Bearer 



Figure 7.3.2.2. 3-1 : ICS UE Origination with CS media without use of 11 and with use of an MSC Server 

enhanced for ICS 

1. The ICS UE uses standard CS originating procedures to establish a CS bearer control signalling session with the 
lUA of the SCC AS by sending a SETUP message to the MSC Server containing the B-party number. 

2. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

3. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the B-party number. If a GRUU 
is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy 
has been requested or public-GRUU if privacy has not been requested. 

4. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC 
AS. 

5. The lUA of the SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for 
presentation of an IMS session towards the B-party on behalf of ICS UE A. The lUA creates a SIP INVITE 
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containing the SDP received in the CS Bearer Control SignalHng Path, indicating CS voice media. The INVITE 
request is routed from the SCC AS to the S-CSCF. 

6. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B- 
party. 

7. Completion of the CS Bearer Control Signalling Path setup procedures. 

For video call, in Step 7, handling of video calls as specified in clause 7.3.2.2.1 Overview apply. 

Figure 7.3.2.2.3-2 provides an example flow for a session origination by an ICS UE where the II reference point is not 
required to set up the session and a MSC Server enhanced for ICS is not used to set-up the CS bearer control signalling. 
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Figure 7.3.2.2.3-2: ICS UE Origination with CS media without use of 11 and with use of an MSC Server 

Steps 1-2 in Figure 7.3.2.2. 3-2 are identical to steps 1-5 in Figure 7.3.2.2. 3-1. 

In Steps 3 and 4, IN (e.g. CAMEL) origination triggers are used at the MSC Server for fetching of an IP Multimedia 
Routing Number (IMRN). The MSC Server sends an I AM to an MGCF using the IMRN which is subsequently inter- 
worked to an INVITE. In Step 5, the S-CSCF carries out standard processing of originating initial filter criteria and 
sends the INVITE to the SCC AS. This step is skipped if the I-CSCF routes the INVITE request directly to the SCC AS. 

Steps 6-8 in Figure 7.3.2.2. 3-2 are identical to steps 5-7 in Figure 7.3.2.2. 3-1. 

NOTE: The method for discovery of original called number and calling party number at the SCC AS if ISUP does 
not provide this information is implementation dependant. This can be realized by interactions between 
the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this 
specification. 

For video call, in Step 8, handling of video calls as specified in clause 7.3.2.2.1 Overview apply. 



7.3.2.2.4 



Originations with CS media using the Gm reference point 



Figure 7.3.2.2.4-1 provides an example flow for a session origination by an ICS UE attached to an MSC Server 
enhanced for ICS where the Gm reference point is used to set up the session with the CS media bearer. 
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Figure 7.3.2.2.4-1: ICS UE Origination with CS media using Gm reference point wlien using an MSC 

Server enhanced for ICS 

NOTE 1 : The steps with non-bold text are related to the setup of the Service Control Signalling Path. The steps 
with bold text are related to the CS Bearer Control Signalling Path. 

1. The ICS UE A sets up a Service Control Signalling Path by initiating a standard IMS origination session towards 
the UE B. A SIP INVITE request (indicating the use of CS media for the session) is sent to the S-CSCF serving 
the UE A in the home IMS network. 

2. The SCC AS is inserted in the IMS session path using originating initial filter criteria at the S-CSCF. The SCC 
AS is the first AS inserted in the session path. 

3. The SCC AS allocates a PSI DN and sends it to the ICS UE A. 

4. The SCC AS returns the SCC AS PSI DN in a reUable provisional response to the S-CSCF 

5. The S-CSCF forwards the provisional response (containing the SCC AS PSI DN) to ICS UE A. 

6. The ICS UE uses standard CS originating procedures to establish the CS Bearer Control Signalling Path with the 
SCC AS by sending a CS call setup message to the MSC Server containing the SCC AS PSI DN. 

NOTE 2: The UE waits for the SIP response (step 5) before the UE generates the CS call setup. 

7. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 
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8. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to 
be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has 
been requested or public-GRUU if privacy has not been requested. 

9. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC 
AS. 

10. The SCC AS invokes a B2BUA, terminating the Access Leg and originating the Remote Leg for presentation of 
an IMS session towards the B -party on behalf of ICS UE A. The SCC AS correlates the CS bearer control 
signalling with the service control signalling and combines both the SDP offers into one offer towards the UE B. 
The SCC AS inserts the SDP received on the CS Bearer Control SignalHng Path into the INVITE indicating CS 
media towards the B-party. The INVITE request is routed from the SCC AS to the S-CSCF. 

IL The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B- 
party 

12. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. 

Figure 7.3.2.2.4-2 provides an example flow for a session origination by an ICS UE attached to an MSC Server where 
the Gm reference point is used to set up the session with the CS media bearer. 
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Figure 7.3.2.2.4-2: ICS UE Origination witli CS media using Gm reference point wlien using an MSC 

Server 

NOTE 3: The steps with non-bold text are related to the setup of the Service Control Signalling Path. The steps with 
bold text are related to the CS Bearer Control Signalling Path. 

Steps 1-7 in Figure 7.3.2.2.4-2 are identical to steps 1-7 in Figure 7.3.2.2.4-1. 

At Steps 8 and 9, the MSC server sends the lAM using the SCC AS PSI DN to an MGCF which is subsequently inter- 
worked to an INVITE. 

Steps 10-13 in Figure 7.3.2.2.4-2 are identical to steps 9-12 in Figure 7.3.2.2.4-1. 
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7.4 Terminations 

7.4.1 Terminating sessions using PS media 

When the ICS UE has access to a PS network that supports the full duplex speech component of an IMS service, 
terminating IMS procedures (as described in clause 5.7 of TS 23.228[2]) shall be used to terminate the session to the 
ICS UE. The S-CSCF shall insert the SCC AS in the IMS session path using terminating initial filter criteria. The SCC 
AS shall be the last AS inserted into the session path. 

7.4.2 Terminating sessions using CS media 
7.4.2.1 Non ICS UE ternninating sessions using CS media 

7.4.2.1.1 Overview 

All ICS User incoming sessions are directed to IMS for delivery to the ICS User. 

Non ICS UEs which have been successfully registered in IMS by the MSC Server will have a registration binding at the 
S-CSCF containing the MSC Server as the contact address. 

The SCC AS shall be inserted in the IMS session path using the terminating iFC. The SCC AS performs T-ADS for 
selection of an access and returns information to assist with S-CSCF selection of a registered contact address. When the 
T-ADS function selects the MSC Server, the SCC AS directs the IMS terminating session towards the contact address 
ofthe MSC Server. 

On receipt of the session initiation message, the MSC Server enhanced for ICS shall perform the necessary 
interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.008 [6]). The MSC Server 
shall also control a CS-MGW using the Mc reference point to perform the necessary interworking between RTP bearers 
on the Mb reference point and CS access bearers. 

Non ICS UEs which are not registered in IMS might still be attached to the CS network at a MSC . In this scenario, the 
unregistered iFC forward the call to the T-ADS function in the SCC AS which selects breakout to the CS domain. A 
CSRN is fetched for routing the call to the CS domain. The INVITE is sent to the S-CSCF which then performs CS 
breakout according to standard IMS procedures. 

7.4.2.1 .2 Termination using 12 reference point 

Figure 7.4.2.1.2-1 describes how IMS terminations are performed via CS access for non ICS UE registered in IMS. 
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Figure 7.4.2.1.2-1 : IMS Termination via CS Access for non ICS UE registered in IMS 

1 . An incoming INVITE is received at the S-CSCF of the B-party. 

2. The S-CSCF performs standard service control execution procedures. Filter criteria direct the S-CSCF to send 
the INVITE to the SCC AS. 

3. The SCC AS performs terminating access domain selection. The SCC AS chooses the CS access network and 
the MSC Server contact address for the setup of the media. 

4. The INVITE is sent to the S-CSCF. 

5. The S-CSCF forwards the INVITE to the MSC Server based on the contact address stored during registration, 
using standard IMS procedures. 

6. The MSC Server sends a Setup message to non ICS UE B. 

7. Completion of the session and bearer control setup procedures. 

7.4.2.1 .3 Termination to non ICS UE not registered in IIVIS 

Figure 7.4.2.1.3-1 describes how IMS terminations are performed via CS access for non ICS UE not registered in IMS. 
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Figure 7.4.2.1.3-1 : IMS Termination via CS Access for non ICS UE not registered in IMS 

1 . An incoming INVITE is received at the S-CSCF of the B-party. 

2. The S-CSCF performs standard unregistered service control execution procedures. The terminating iFC direct 
the INVITE to the SCC AS for terminating access domain selection. 

3. The T-ADS function chooses breakout to the CS domain. A CSRN is fetched for routing to the CS domain. 

4. An INVITE is returned to the S-CSCF. 

5. The S-CSCF then performs CS breakout according to existing IMS procedures. The call is routed to the CS 
domain via the BGCF/MGCF. 

6. Completion of the session and bearer control setup procedures. 



7.4.2.2 



ICS UE Ternninating sessions using CS media 



7.4.2.2.1 



Overview 



IMS session control is used for ICS UE terminating sessions established with use of CS media bearer. 

All ICS User incoming sessions are directed to IMS for delivery to the ICS User. The SCC AS is inserted in the IMS 
session path using the terminating iFCs. The SCC AS performs T-ADS for selection of a contact address amongst the 
registered contact addresses for the ICS User and subsequently selects an access network for delivery of the session to 
the selected contact address. 

When using the Gm reference point for delivery of the incoming session to the ICS UE, the SCC AS directs the IMS 
terminating session toward the ICS User"s selected contact indicating use of CS bearer for the session. On receipt of the 
session initiating message, the ICS UE sets up a standard CS originated session addressing a PSI DN associated with 
the SCC AS to establish the CS bearer. The session control signalling is combined with the description of the CS bearer 
at the SCC AS for presentation of IMS terminating session to the S-CSCF over the Remote Leg. 

The following clauses show pairs of flows, one for an ICS UE when using an MSC Server and the other for an MSC 
Server enhanced for ICS. They are for the most part identical except that in the case of an MSC Server enhanced for 
ICS the INVITE towards the SCC AS is sent directly from the MSC Server otherwise an MSC sends an ISUP lAM and 
the MGCF interworks this to an INVITE towards the SCC AS. 



7.4.2.2.2 



Terminations with 08 media using the Gm reference point 



Figure 7.4.2.2.2-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for 
ICS, where the incoming session is delivered over the Gm reference point and the media is established via the CS 
network. 
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Figure 7.4.2.2.2-1: ICS UE Terminations with CS media information flows using Gm reference point 

when using an MSC Server enhanced for ICS 

NOTE 1: Steps 11, 12,13 and 14 are related to the setup of the CS Bearer Control Signalling Path. The other steps 
are related to the setup of the Service Control Signalling Path.. 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party from UE A. 
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2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS. 

3. The SCC AS sends a Session Progress response to the S-CSCF. 

4. The S-CSCF forwards the Session Progress response to UE A. 

Steps 5a - 7a are for the case of T-ADS performed by the SCC AS. 

5a. The SCC AS performs Terminating Access Domain Selection and chooses the CS domain for the setup of the 
media. 

6a. The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to 
the B -party via the I/S-CSCF. This INVITE contains an indication to inform the UE to initiate the CS bearer 
establishment procedure. The INVITE also contains a dynamic SCC AS PSI to enable the SCC AS to later on 
correlate the outgoing service control signalling with the incoming CS bearer control signalling. When the T- 
ADS function selects the Gm reference point for service control the SCC AS prevents the S-CSCF from 
selecting the contact address of the MSC Server, and the S-CSCF selects the IP-CAN 

7a. The I/S-CSCF sends the INVITE to B-party. 

Steps 5b - 10 are for the case of UE assisted T-ADS. 

5b. Alternatively, in the case of UE assisted T-ADS the SCC AS performs initial T-ADS selecting IMS for the 
service control signalling when UE-B is registered in the IMS. 

6b The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to 
the B-party via the I/S-CSCF. the INVITE contains options that enable UE-B to choose a CS bearer for 
bidirectional speech media transport if it determines that this is not supported by serving PS Access Network. 
The INVITE also contains a dynamic SCC AS PSI to enable the SCC AS to later on correlate the outgoing 
service control signalling with the incoming CS bearer control signalling. When the T-ADS function selects 
the Gm reference point for service control, the SCC AS prevents the S-CSCF from selecting the contact 
address of the MSC Server, and the S-CSCF selects the IP-CAN. 

7b. The I/S-CSCF sends the INVITE to B-party. 

8-10 UE-B responds with a Session Progress message. In the case that the PS access network does not support 
bidirectional speech media, UE-B shall indicate in the Session Progress message that a CS bearer is required 
for the bidirectional speech component of the session. The S-CSCF forwards the Session Progress message to 
the SCC AS. 

1 1. The ICS UE sends a CS call setup message to the MSC Server using the SCC AS PSI DN to estabHsh the CS 
Bearer Control Signalling Path. This will establish the circuit bearer between the UE and IMS. 

12. The MSC Server responds with a call proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

13. The MSC Server sends an INVITE towards the I/S-CSCF containing the SCC AS PSI and an SDP Offer with the 
media description from the MGW. 

14. The I/S-CSCF forwards the INVITE to the SCC AS. 

15. The SCC AS continues the session setup towards the A-party for the original INVITE in Step 1. The response 
contains an SDP answer with the media description from the SDP offer received in Step 10. 

16. The SCC AS completes the set-up of the CS Bearer Signalling Path towards ICS UE B which involves sending a 
200 OK in response to the INVITE in Step 1 1. The ICS UE B, the MSC Server and the SCC AS complete the 
setup of the CS Bearer Control Signalling Path and the Service Control Signalling Path with UE A. 

17. The ICS UE B continues with the set-up of the Service Control Signalling Path towards the UE A which includes 
sending a Ringing response to the SCC AS via the S-CSCF. The ICS UE B then completes the set-up of the 
Service Control Signalling Path towards the Remote End which includes sending a final 200 OK message in 
response to the INVITE received at step 7. 

Figure 7.4.2.2.2-2 provides an example flow for a call destined to an ICS UE attached to an MSC server, where the 
incoming session is delivered over the Gm reference point and the media is established via the CS network. 
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Figure 7.4.2.2.2-2: ICS UE Terminations with CS media information flows using Gm reference point 

when using an MSC Server 

NOTE 2: Steps 11, 12,13,14 and 15 are related to the setup of the CS Bearer Control Signalling Path. The other 
steps are related to the setup of the Service Control Signalling Path. 

Steps 1-12 in Figure 7.4.2.2.2-2 are identical to steps 1-9 in Figure 7.4.2.2.2-1. 
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At Steps 13 and 14, the MSC server sends the lAM to an MGCF using the SCC AS PSI DN which is subsequently 
inter- worked to an INVITE containing the SCC AS PSI and an SDP Offer from the MGW. 

Steps 15-18 in Figure 7.4.2.2.2-2 are identical to steps 14-17 in Figure 7.4.2.2.2-1. 

7.4.2.2.3 Terminations with CS media using the 11 reference point 

Figure 7.4.2.2.3-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for 
ICS, where the incoming session is delivered over the II reference point and the media is established via the CS 
network. 
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Figure 7.4.2.2.3-1 : ICS UE Terminations witli CS media information flows using 11 reference point 

when using an MSC Server enhanced for ICS 

NOTE 1: Steps 1-10, 15 and 17-22 are related to the setup of the Service Control Signalling Path. Steps 11-14 and 
16 are related to the setup of the CS Bearer Control Signalling Path. 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party from UE A. 

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS. 
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3. The sec AS sends a Session Progress response to the S-CSCF. 

4. The S-CSCF forwards the Session Progress response to UE A. 

Steps 5a - 6a are for the case of T-ADS performed by the SCC AS. 

5a. The SCC AS performs Terminating Access Domain Selection and if informed of the UE capabiHty for II 
during IMS registration, chooses the CS domain for the setup of the media. 

NOTE 2: Conveyance of UE capabiHty of support for II does not imply that II can be established (e.g. the visited 
network does not support II). 

6a. The SCC AS terminates the session from the A-party and establishes a new session over II by sending an 
Incoming Call Request to the B -party via the HSS and MSC Server. The Incoming Call Request contains an 
indication to inform the UE to initiate the CS bearer establishment procedure. The Incoming Call Request 
also contains a dynamic SCC AS PSI (DN) to enable the SCC AS to later on correlate the outgoing service 
control signalling with the incoming CS bearer control signalling. 

Steps 5b - 10 are for the case of UE assisted T-ADS. 

5b. Alternatively, in the case of UE assisted T-ADS the SCC AS performs initial T-ADS selecting IMS for the 
service control signalling when UE-B is registered in the IMS. 

6b The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to 
the B-party via the I/S-CSCF. The INVITE contains options that enable UE-B to choose a CS bearer for 
bidirectional speech media transport if it determines that this is not supported by serving PS Access Network. 
The INVITE also contains a dynamic SCC AS PSI (DN) to enable the SCC AS to later on correlate the 
outgoing service control signalling with the incoming CS bearer control signalling. When the T-ADS 
function selects the Gm reference point for service control, the SCC AS prevents the S-CSCF from selecting 
the contact address of the MSC server, and the S-CSCF selects the IP-CAN. 

7b. The I/S-CSCF sends the INVITE to B-party. 

8-10. In the case where the access network does not support simultaneous PS and CS, UE-B responds with a 
Session Progress message. UE-B shall indicate in the Session Progress message that a CS bearer is required 
for the session and that further signalling for the session will be via II. The S-CSCF forwards the Session 
Progress message to the SCC AS. 

1 1. The ICS UE sends a CS Setup message to the MSC Server using the SCC AS PSI DN to estabHsh the CS Bearer 
Control Signalling Path. This will establish the circuit bearer between the UE and IMS. 

12. The MSC Server responds with a call proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

13. The MSC Server sends an INVITE towards the I/S-CSCF containing the SCC AS PSI and an SDP Offer with the 
media description from the MGW. 

14. The I/S-CSCF forwards the INVITE to the SCC AS. 

15. The SCC AS continues the session setup towards the A-party for the original INVITE in Step 1. The response 
contains an SDP answer with the media description from the SDP offer received in Step 13. 

16. The SCC AS completes the set-up of the CS Bearer Signalling Path towards ICS UE B which involves sending a 
200 OK in response to the INVITE in Step 14. The ICS UE B, the MSC Server and the SCC AS complete the 
setup of the CS Bearer Control Signalling Path and the Service Control Signalling Path with UE A. 



17. UE-B sends a Ringing indication to the SCC AS via II. 

18-19. The SCC AS sends a Ringing message to the remote end. 

20. UE-B sends a Connecting message to the SCC AS via II. 

21-22. The SCC AS sends a 200 OK message to the remote end in response to the INVITE received at step 2. 

Figure 7.4.2.2.3-2 provides an example flow for a call destined to an ICS UE attached to an MSC server where the 
incoming session is delivered over the II reference point and the media is established via the CS network. 
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Figure 7.4.2.2.3-2: ICS UE Terminations with CS media information flows using II reference point 

when using an MSC Server 

NOTE 3: Steps 1-10, 16 and 18-23 are related to the setup of the Service Control Signalling Path. Steps 11-15 and 
17 are related to the setup of the CS Bearer Control Signalling Path. 

Steps 1-12 in Figure 7.4.2.2.3-2 are identical to steps 1-12 in Figure 7.4.2.2.3-1. 
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At Steps 13 and 14, the MSC server sends the lAM to an MGCF using the SCC AS PSI DN which is subsequently 
inter- worked to an INVITE containing the SCC AS PSI and an SDP Offer from the MGW. 

Steps 15-23 in Figure 7.4.2.2.3-2 are identical to steps 14-22 in Figure 7.4.2.2.3-1. 



7.4.2.2.4 



Terminations with CS media using CS control with 11 augmentation 



Standard CS terminating procedures are used to deHver the incoming session to the ICS UE as described in Figure 
7.4.2.2.3-1 when the ICS UE is attached to an MSC server enhanced for ICS, and in Figure 7.4.2.2.3-2 when the ICS 
UE is attached to an MSC server. Additional IMS parameters can be optionally communicated to the ICS UE using II 
after the incoming session has been delivered. 



7.4.2.2.5 



Terminations with CS media when not using Gm or 11 



Figure 7.4.2.2.5-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for 
ICS, where the incoming session is delivered using standard CS terminating procedures. 
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Figure 7.4.2.2.5-1: ICS UE Termination with CS media using standard CS terminating procedures 

when using an MSC Server enhanced for ICS 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party. 

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS. 

3. The SCC AS terminates the session from the A-party and performs terminating access domain selection to select 
a contact address for the chosen access network amongst the registered contact addresses for the ICS User. The 
SCC AS chooses the CS access network for the setup of the media. 

4. The SCC AS establishes a new session by sending an INVITE to the B-party via the I/S-CSCF. 

5. The S-CSCF forwards the message to the MSC Server based on the contact address stored during registration, 
i.e. using standard S-CSCF procedures. 

6. The MSC Server performs paging procedures and sends the CS call setup message to ICS UE B 
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7. The ICS UE completes the setup of the CS Bearer Control SignaUing Path towards UE-A via the SCC AS. 

Figure 7.4.2.2.5-2 provides an example flow for a call destined to an ICS UE attached to an MSC server where the 
incoming session is delivered using standard CS terminating procedures. 
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Figure 7.4.2.2.5-2: ICS UE Termination with CS media using standard CS terminating procedures 

when using an MSC Server 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party. 

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS. 

3. The SCC AS terminates the session from the A-party and performs terminating access domain selection and 
chooses the CS access network for the setup of the media. A CSRN is fetched for the user. 

NOTE 3: Fetching the CSRN is an implementation specific. 

4. The SCC AS establishes a new session by sending an INVITE containing the CSRN towards the S-CSCF. 

5. The S-CSCF performs breakout to the CS domain by routing the call via the MGCF, according to existing IMS 
procedures. 

6. The MGCF sends an ISUP lAM to the MSC Server. 

7. The MSC Server performs paging procedures and sends the CS call setup message to ICS UE B 

8. The ICS UE completes the setup of the CS Bearer Control Signalling Path towards UE-A via the SCC AS. 

7.4.2.2.6 Terminations with CS media using the Gm reference point in case of fall back to 

11 indicated by UE assisted T-ADS 

Figure 7.4.2.2.6-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for 
ICS, where initial incoming session is signalled over the Gm reference point, but simultaneous PS and CS is not 
supported. The UE indicates this and establishes media via the CS network with subsequent signalling via II. 
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Figure 7.4.2.2.6-1 :Termination to ICS UE via Gm reference point witli fall back to 11 in case where 
access network is not capable of simultaneous CS and PS operation. 

NOTE 1: Steps 11, 12,13 and 14 are related to the setup of the CS Bearer Control Signalling Path. The other steps 
are related to the setup of the Service Control Signalling Path. 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party from UE A. 

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS. 

3. The SCC AS sends a Session Progress response to the S-CSCF. 

4. The S-CSCF forwards the Session Progress response to UE A. 

5. The SCC AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in 
the IMS. 

6 The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to the 
B-party via the I/S-CSCF. the INVITE contains options that enable UE-B to choose a CS bearer for bidirectional 
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speech media transport if it determines that this is not supported by serving PS Access Network. The INVITE 
also contains a dynamic SCC AS PSI to enable the SCC AS to later on correlate the outgoing service control 
signalling with the incoming CS bearer control signalling. When the T-ADS function selects the Gm reference 
point for service control, the SCC AS prevents the S-CSCF from selecting the contact address of the MSC 
Server, and the S-CSCF selects the IP-CAN. 

7. The I/S-CSCF sends the INVITE to B-party. 

8-10. In the case where the access network does not support simultaneous PS and CS, UE-B responds with a 
Session Progress message. UE-B shall indicate in the Session Progress message that a CS bearer is required for 
the session and that further signalling for the session will be via II. The S-CSCF forwards the Session Progress 
message to the SCC AS. 

1 1. The ICS UE sends a SETUP message to the MSC Server using the SCC AS PSI DN to establish the CS Bearer 
Control Signalling Path. This will establish the circuit bearer between the UE and IMS. 

12. The MSC Server responds with a call proceeding message and begins to set up the CS Bearer Control Signalling 
Path. 

13. The MSC Server sends an INVITE towards the I/S-CSCF containing the SCC AS PSI and an SDP Offer with the 
media description from the MGW. 

14. The I/S-CSCF forwards the INVITE to the SCC AS. 

15. The SCC AS continues the session setup towards the A-party for the original INVITE in Step 1. The response 
contains an SDP answer with the media description from the SDP offer received in Step 10. 

16. The SCC AS completes the set-up of the CS Bearer Signalling Path towards ICS UE B which involves sending a 
200 OK in response to the INVITE in Step 1 1. The ICS UE B, the MSC Server and the SCC AS complete the 
setup of the CS Bearer Control Signalling Path and the Service Control Signalling Path with UE A. 

17. UE-B sends a Ringing indication to the SCC AS via II. 
18-19. The SCC AS sends a Ringing message to the remote end. 
20. UE-B sends a Connecting message to the SCC AS via II. 

21-22. The SCC AS sends a 200 OK message to the remote end in response to the INVITE received at step 2. 

Figure 7.4.2.2.6-2 provides an example flow for a call destined to an ICS UE attached to an MSC server, where initial 
incoming session is signalled over the Gm reference point, but simultaneous PS and CS is not supported. The UE 
indicates this and establishes media via the CS network with subsequent signalling via II. 
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Figure 7.4.2.2.6-2: Termination to ICS UE via Gm reference point with fall back to 11 in case where 
access network is not capable of simultaneous CS and PS operation, and without MSC Server 

enhanced to support ICS 

NOTE 2: Steps 11, 12,13,14 and 15 are related to the setup of the CS Bearer Control SignalHng Path. The other 
steps are related to the setup of the Service Control Signalling Path. 

Steps 1-12 in Figure 7.4.2.2.4-2 are identical to steps 1-9 in Figure 7.4.2.2.4-1. 

At Steps 13 and 14, the MSC server sends the lAM to an MGCF using the SCC AS PSI DN which is subsequently 
inter- worked to an INVITE containing the SCC AS PSI and an SDP Offer from the MGW. 

Steps 15-23 in Figure 7.4.2.2.6-2 are identical to steps 14-22 in Figure 7.4.2.2.6-1. 



7.5 Service continuity 

7.5.1 Service continuity for ICS UE 



7.5.1.1 



7.5.1.1.1 



Service continuity while maintaining the use of CS access for the media 



IIVIS sessions established using Gm reference point 



7.5.1.1.1.1 



Overview 



When the CS bearer is used for the media of the IMS session, the Gm reference point may be used for communication 
of service control signalling, contingent upon the VPLMN support of the Gm reference point. A change of access 
network due to handover (e.g. as described in TS 23.009 [22] and TS 25.413 [23]), may result in an inability to use the 
PS access for the Gm reference point while the use of CS access for the media of the IMS session is still possible; under 
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such circumstance, the service continuity is maintained by switching the signalling transport over to the CS access, e.g. 
by switching the use of Gm with the II reference point or to not using Gm or II. 



7.5.1.1.1.2 



Use of Gm reference point possible after handover 



Standard Handover procedures, that are specific to different access networks (e.g. as described in TS 23.009 [22] and 
TS 25.413 [23]), are used for handover of the Service Control Signalling Path and the CS Bearer Control Signalling 
Path along with the associated circuit bearer to the target access network. 

The use of Gm reference point for Service Control Signalling Path is maintained upon handover. 



7.5.1.1.1.3 



Use of Gm reference point not possible after Handover 



Standard CS handover procedures, see TS 23.009 [22] and TS 25.413 [23], are used to relocate the CS Bearer Control 
Signalling Path and the associated circuit bearer to the target access network. Upon completion of the handover of the 
CS Bearer Control Signalling Path and the associated circuit bearer to the target access, the UE sends a handover 
notification message to the SCC AS to indicate use of II for the Service Control Signalling Path if the II reference point 
is available in the target access network or to fallback to not using Gm or II. 

After handover, the II reference point is used for session control signalling in networks supporting the II reference 
point; the non ICS UE procedures apply in networks not supporting the II reference point. 

If the SCC AS detects that the ICS UE is not reachable over Service Control Signalling Path, the SCC AS should clear 
all held sessions related to the user if any are present, and update the remote leg if necessary. 

NOTE 1 : It is implementation issue of detecting loss of the Service Control Signalling Path. 

NOTE 2: In order to avoid unintentional release of an ongoing ICS session, an ICS UE can re-register its public 
user identity with the IMS at a time chosen to minimize the probability of its IMS registration expiring 
during an ongoing ICS session when Gm is not available. To prevent the ICS UE requesting re- 
registration with unacceptable frequency, the Registrar in a network implementing ICS would need to set 
the IMS registration expiry timer to an appropriate value. 

Figure 7.5.1.1.1.3-1 is an example call flow of releasing the held session at the SCC AS when the SCC AS detects that 
the ICS UE is not reachable over Service Control Signalling Path. 



ICS UE A 



MSC 



MGCF 



MGW 



S-CSCF 



SCC AS 



UE B 



UE C 



session between ICS UE A & UE B active, session(s) between UE A & UE C on liold 



1 . Detection of Service Control 
Signaling Path unavailable 



2. Release of held session(s) 



3. Update 



4. Update 



Figure 7.5.1.1.1.3-1: release of held sessions at SCC AS when Service Control Signalling Path 

unavailable 

1. The SCC AS detects that the ICS UE is not reachable over Service Control Signalling Path. 

2. The SCC AS releases the held session between UE A and UE C. 

3. The SCC AS sends the UPDATE to the S-CSCF. 

4. The S-CSCF forwards the UPDATE to the UE B to update the remote leg. 
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7.5.1 .2 Service continuity when transferring the media of IMS sessions between PS 

and CS access 

See TS 23.237 [12] IMS Service Continuity. 

7.6 Consistency of supplementary services 
7.6.1 Supplementary Services for ICS UE 

7.6.1.1 Overview 

When the IP-CAN is used for the media of the IMS session, IMS procedures as defined in TS 24.173 [8] apply for IMS 
services. 

When the CS bearer is used for the media of the IMS session, the Gm or the II reference point is used for 
communication of service control signalling; IMS services are provided to the ICS UE with the lUA of the SCC AS 
combining the service control signalling communicated over the Gm or the II reference point with the description of the 
CS bearer for the execution of service control over the Remote Leg. The lUA provides functions necessary for use of 
CS bearer in conjunction with the IMS service control for standard IMS service behaviour on the Remote Leg. 

7.6.1 .2 IMS sessions using CS bearer 

7.6.1.2.1 Overview 

When the CS bearer is used for the media of the IMS Multimedia Telephony service, see TS 22.173 [4], the procedures 
specified in this clause apply. 

7.6.1 .2.2 Use of Gm reference point 

7.6.1 .2.2.1 Line ID Services (OIP, OIR, TIP, TIR) 

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with 
the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document. 

7.6.1 .2.2.2 Communication Diversion Services 

IMS procedures as defined in TS 24.173 [8] apply with the lUA of the SCC AS combining the description of the CS 
bearer with the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this 
document. 

7.6.1.2.2.3 Communication Barring 

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with 
the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document. 

7.6.1.2.2.4 Communication Hold/Resume 

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with 
the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Communication 
Hold/Resume. 

Figure 7.6.1.2.2.4-1 provides the ICS Communication Hold/Resume flow over Gm reference point for the ICS UE. 
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ICS UE A 



MSC Server 



MGCF 



IMS-MGW 



sec AS 



I/S- CSCF 

I 



UE B 



Session between ICS UE A and UE B active 



-LHold- 



-6. IVIedia Update- 



-2. Hold- 



-3. Hold- 



-5. IVIedia Update ►■ 



7. Completion of communication hold between UE A & UE B 



-8. Resume- 



-13. Media Update- 



-10. Resume- 



-12. Media Update 



-11. Resume- 



14. Completion of communication resume between UE A & UE B 



Figure 7.6.1.2.2.4-1 : ICS Communication Hold/Resume over Gm reference point 

1. The ICS UE A sends a Hold request to the S-CSCF as specified in TS 23.228 [2] and TS 24.173 [8]. The hold 
request indicates whether the media shall continue to be sent to the remote party or not.. 

2. The S-CSCF forwards the Hold request to the SCC AS based upon filter criteria. 

3. The SCC AS sends the Hold request to the S-CSCF indicating the remote party shall stop sending the media and, 
according to the hold request, continue or stop receiving media from the invoking UE.. 

4. The S-CSCF sends the Hold request to UE B. 

5. The SCC AS sends an media update requestto the S-CSCF indicating the media is held. 

6. The S-CSCF forwards the media update requestto the MGCF Depends on what information is exactly contained in 
the request, MGCF could send call hold request towards the CS network according to TS 29.163 [xx]. If the ICS 
UE A receives this request from MGCF, it shall ignore it.. 

NOTE 1: Steps 5-6 can be executed in parallel with steps 3-4. 

7. Completion of communication hold between UE A and UE B based on the procedures specified in TS 23.228 [2]. 
NOTE 2: After the session is put on hold, UE A may initiate a new session and the existing CS bearer can be reused. 

8. The ICS UE A sends a Resume request to the S-CSCF as specified in TS 23.228 [2] and TS 24.173 [8]. 

9. The S-CSCF forwards the Resume request to the SCC AS based upon filter criteria. 

10. The SCC AS sends the Resume request to the S-CSCF. 

1 1. The S-CSCF sends the Resume request to UE B. 

12. The SCC AS sends a media update request to the S-CSCF indicating the media is resumed. 

13. The S-CSCF forwards the media update request to the MGCF. 
NOTE 3: Steps 12-13 can be executed in parallel with steps 10-11. 

14. Completion of communication resume between UE A and UE B based on the procedures specified in 
TS 23.228 [2]. 
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7.6.1.2.2.5 



Explicit Communication Transfer 



IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with 
the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Explicit 
Communication Transfer. 



7.6.1.2.2.5.1 



Consultative ECT using Gm reference point, ICS UE as transfer recipient 



Figure 7.6.1.2.2.5.1-1 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer 
recipient using Gm interface. The UE A has a held call with UE C and an ongoing call with ICS UE B before transfer. 
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- 16. Notify (transfer complete)- 



17. Notify (transfer 
complete) 
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complete) 



15. Session release between C & A 



- 19. Notify (transfer complete)- 



20. Session release between A & B 



Figure 7.6.1.2.2.5.1-1 : IMS Consultative ECT via Gm for ICS UE (transfer recipient) 

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER request as specified in TS 24.173 [8]. 

2. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabHshment. 

3. The SCC AS sends the REFER to the S-CSCF. 

4. The S-CSCF sends the REFER to the ICS UE B. 

5. The ISC UE B initiates session estabHshment towards UE C by initiating an INVITE message. 

6. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS. 

7. The INVITE is sent to the S-CSCF. 

8. The S-CSCF routes the request to UE C. 

9.-12. UE C sends back session progress messages to the ISC UE B via S-CSCF and SCC AS. 
13. SCC AS sends a backward message to MGCF to update MGW port for connecting with UE C. 
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14. A session is established between the ICS UE B and UE C. 

15. UE C release the session with UE A. 

16. The ICS UE B provides indication that the communication transfer is complete by sending a NOTIFY message 
as specified in TS 24.173 [8]. 

17. The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment. 

18. The SCC AS sends the NOTIFY to the S-CSCF. 

19. The NOTIFY is sent to UE A. 

20. The UE A initiates session release with ICS UE B and release the session. 

NOTE: In case that If MSC Server enhanced for ICS is deployed rather than the MSC/MGCF, it plays the role of 
VMSC/MGCFthese same flows apply. 

7.6.1 .2.2.5.2 Blind ECT using Gm reference point, ICS UE as transfer recipient 

Figure 7.6.1.2.2.5.2-1 describes how IMS blind ECT is performed when ICS UE is playing the role of transfer recipient 
using Gm interface. The UE A has a held call with ICS UE B and no session with UE C before transfer. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Communication 
ECT. 
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Figure 7.6.1.2.2.5.2-1 : IMS blind ECT via Gm for ICS UE (transfer recipient) 

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER as specified in TS 24.173[8]. 

2. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabHshment. 

3. The SCC AS acknowledges the REFER message as a blind transfer request for ICS UE B and sends the REFER 

to the S-CSCF. 

4. The S-CSCF sends the REFER to the ICS UE B. 

5. ICS UE B accepts the transfer request. 

6. The S-CSCF sends the accept message to the SCC AS as it was inserted at session establishment. 

7. The SCC AS sends the accept message to the S-CSCF. 

8. The S-CSCF sends the accept message to the UE A. 

9. On reception of the accept message from the ICS UE B, UE A initiates the session release with the ICS UE B by 

initiating a BYE message to ICS UE B. 

10. The S-CSCF sends the BYE to the SCC AS as it was inserted at session establishment. On reception of the BYE, 
the ICS UE B only release the PS session signalling path with UE A and keep the CS bearer. 
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1 1. The sec AS sends the BYE to the S-CSCF. 

12. The S-CSCF sends the BYE to the ICS UE B. 

13. Session between UE A and ICS UE B is released. The CS bearer from ICS UE B and MGW is kept for further 
reuse. 

Editor" s note: It is FES how to retain the CS bear when needed. 

14. The ISC UE B initiates session estabHshment towards UE C by initiating an INVITE message. 

15. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS. 

16. The INVITE with the MGW SDP received from the MSC Server/ MGCF upon UE A-UE B session 
establishment is sent to the S-CSCF. 

17. The S-CSCF routes the request onwards to UE C. 

18.-21. UE C sends back session progress messages to the ICS UE B via S-CSCF and SCC AS. 

22. SCC AS sends a backward message to MGCF to update the MGW port for connecting with UE C. 

23. A session is established between the ICS UE B and UE C. 

24. The ICS UE B provides indication that the communication transfer is complete by sending a NOTIFY as 
specified in TS 24.173 [8]. 

25. The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session estabHshment. 

26. The SCC AS sends the NOTIFY to the S-CSCF. 

27. The NOTIFY is sent to UE C as specified in TS 24.173 [8]. 

NOTE: If MSC Server enhanced for ICS is deployed rather than the MSC/MGCF, these same flows apply.In case 
that MSC Server enhanced for ICS is deployed, it plays the role of VMSC/MGCF. 



7.6.1.2.2.6 Conferencing 

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with 
the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Conferencing. 

Figure 7.6.1.2.2.6-1 describes how ICS UE executes the IMS conferencing when using Gm interface. The ICS UE A 
has a held call with UE B and an ongoing call with UE C before it initiates a conference. 
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Figure 7.6.1.2.2.6-1 : ICS UE executes the IMS Conferencing via Gm 

1. The ICS UE A initiates a session with the conference AS by sending an INVITE to S-CSCF. 

2. The S-CSCF sends the INVITE to the SCC AS as it was inserted at session estabHshment. 

3. The SCC AS sends the INVITE to the S-CSCF. 

4. The INVITE is sent to the conference AS. 

5. A session is estabHshed between the ICS UE A and conference AS as specified in TS 24.173 [8]. 
6.-9. Conference AS sends session progress response to the ICS UE A via S-CSCF and SCC AS. 

10. SCC AS sends a backward message to MGCF to update the MGW port for connecting with the conference AS. 

1 1. UE C is put on hold by SCC AS through interaction with MRF. 

12. The ICS UE A initiates a REFER message indicating UE B transferring the current session to the conference AS 
using Gm interface as specified in TS 24.173 [8]. 

13. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabHshment.. 

14. The SCC AS sends the REFER to the S-CSCF. 
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15. The S-CSCF sends the REFER to UE B. 

16. A session is established between the conference AS and UE B as specified in TS 24.173 [8]. 

17.-20. UE B sends a NOTIFY indicating the transfer completed back to ICS UE A via S-CSCF and SCC AS. 

21. The media between the ICS UE A and UE B is released. 

22. Step 13-21 is repeated for UE C. 

23. The media between the ICS UE A and UE C is released. 

NOTE: If MSC Server enhanced for ICS is deployed rather than the MSC/MGCF, these same flows apply.In case 
that MSC Server enhanced for ICS is deployed, it plays the role of VMSC/MGCF. 

7.6.1 .2.2.7 Communication Waiting 

Figure 7.6.1.2.2.7-1 provides the ICS communication waiting flow over Gm reference point for the ICS UE. 
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Figure 7.6.1.2.2.7-1: ICS UE Communication Waiting over Gm Reference Point 

1 . An incoming INVITE message is received at the S-CSCF of the ICS UE A. 

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE message to the SCC AS. 

3. The SCC AS performs terminating access domain selection and chooses the CS access network for the setup of 
the media. 

4. The SCC AS sends the INVITE message to the S-CSCF. 

5. The S-CSCF sends the INVITE message to UE A. 

6. The ICS UE A sends to the S-CSCF an indication that the call is waiting. 

7. The S-CSCF sends the indication of call waiting to the SCC AS. 

8. The SCC AS sends the indication of call waiting to the S-CSCF. 

9. The S-CSCF forwards the indication of call waiting to UE C. 

10. The ICS UE A sends a Hold message to the S-CSCF as specified in TS 23.228 [2]. 

1 1. The session between UE A and UE B is put on hold as described in clause 7.6.1.2.2.4 Communication 
Hold/Resume. 

12. Completion of the session establishment between UE A and UE C. The existing CS bearer can be reused. 
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7.6.1 .2.3 Use of 11 reference point 

7.6.1 .2.3.1 Line ID Services (OIP, OIR, TIP, TIR) 

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. The 
information specific to Line ID services is communicated over the II reference point when the II reference point is used 
at session setup. 

7.6.1 .2.3.2 Communication Diversion Services 

7.6.1.2.3.2.1 Communication Forwarding Unconditional (CPU) 

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

7.6.1 .2.3.2.2 Communication Forwarding on Not Logged-in (CPNL) 

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

7.6.1 .2.3.2.3 Communication Forwarding Busy (CFB) 

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. When 
II is used for session set-up, the information specific to CFB is communicated over the II reference point; the SCC AS 
performs the necessary interworking between the II signalling and IMS to allow execution of CFB in IMS. 

Figure 7.6.1.2.3.2.3-1 provides the Communication Forwarding Busy (CFB) flow over the II reference point for an ICS 
UE. 
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Figure 7.6.1.2.3.2.3-1 Communication Forwarding on Busy User flow over the II reference point for an 

ICS UE. 

1 An incoming SIP INVITE is received at the S-CSCF of the B party from the A party. 

2-4 The S-CSCF forwards the INVITE to the TAS and SCC AS. 

5 The SCC AS sends an incoming Call Request to the UE over II via the MSC server. 

6-7 The UE rejects the incoming call request as the user is busy and sends a User Determine User Busy (UDUB) 
response over II to the SCC AS. 

8-9 The SCC AS inter- works the UDUB response over II into an appropriate SIP Response to indicate that the B 
party is busy, and sends the SIP Response to the TAS via the CSCF. 

10 The TAS processes the SIP Response and executes the CFB logic. 



7.6.1.2.3.2.4 



Communication Forwarding No Reply (CFNR) 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. The 
information specific to CFNR is communicated over the II reference point when the II reference point is used at 
session setup. 

Figure 7.6.1.2.3.2.4-1 provides the Communication Forwarding No Reply flow over the II reference point for an ICS 
UE. 
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9. CFNR Logic 
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1. INVITE 



Figure 7.6.1.2.3.2.4-1 : Communication Forwarding No Reply flow over the II reference point for an 

ICS UE. 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party from the A party. 

2. The S-CSCF forwards the INVITE to the TAS and SCC AS. 

3. The SCC AS starts a supervisory timer for the call. 

4-5 The TAS forwards the INVITE to the SCC AS via the S-CSCF. 

6. The SCC AS sends an incoming Call Request to the ICS UE over II. 

7. The ICS UE performs CS bearer set-up procedures. 

8. The SCC AS does not receive an answer from the ICS UE and the timer at the TAS expires. 

9. The TAS executes the CFNR logic. 



7.6.1.2.3.2.5 



Communication Forwarding on Subscriber Not Reachable (CFNRc) 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. When 
II is used for call set-up, the SCC AS performs the necessary interworking between the II signalling response and SIP 
to allow execution of CFNRc in IMS. 

Figure 7.6.1.2.3.2.5-1 provides the Communication Forwarding on Subscriber Not Reachable flow over the II reference 
point for an ICS UE. 
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Figure 7.6.1.2.3.2.5-1 Communication Forwarding Not Reachable flow over the II reference point for 

an ICS UE. 

1 . An incoming SIP INVITE is received at the S-CSCF of the B party from the A party. 

2-4. The S-CSCF forwards the INVITE to the TAS and SCC AS. 

5. The SCC AS or MSC Server determines that the user is not reachable, for example: 

- The MSC Server pages the ICS UE B and no response to the page message is received. 

- The MSC Server itself determines that the user is not reachable (e.g. IMSI detach). 

- The MSC Server pages the ICS UE B and a page response is received but the CS bearer set up procedures 
fail. 

6-7. The SCC AS sends an appropriate SIP response that indicates that the user is unreachable to the TAS via the 
CSCF. 

8. The TAS processes the SIP response and executes the CFNRc logic. 



7.6.1.2.3.2.6 



Communication Deflection (CD) 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. When 
II is used for call set-up, the information specific to CD is communicated over the II reference point; the SCC AS 
performs the necessary interworking between the II signalling and SIP to allow execution of CD in IMS. 

Figure 7.6.1.2.3.2.6-1 provides the Communication Deflection (CD) flow over the II reference point for an ICS UE. 
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Figure 7.6.1.2.3.2.6-1 Communication Deflection flow over the II reference point for an ICS UE 

1 An incoming SIP INVITE is received at the S-CSCF of the B party from the A party. 

2-4 The S-CSCF forwards the INVITE to the TAS and SCC AS. 

5 The SCC AS sends an incoming Call Request to the UE over II via the MSC server. 

6-7 The user decides to deflect the call and the UE returns a Call Deflection Request to the SCC AS over II 
indicating the deflected-to party. 

8-9 The SCC AS inter- works the Call Deflection Request received over II into an appropriate SIP response and 
sends the SIP response to the TAS via the CSCF. 

10 The TAS processes the SIP response and executes the CD logic. 



7.6.1.2.3.2.7 



Communication Diversion Notification (CDIVN) 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

When II is used for call set-up, the SCC AS performs the necessary interworking between the II signalling and SIP to 
subscribe to the comm-div-info event package at the TAS on behalf of the UE and to receive and propagate to the UE, 
the notification that the call was diverted. 



7.6.1.2.3.3 



Communication Barring 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 



7.6.1.2.3.4 



Communication Hold/Resume 



IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 
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Figure 7. 6.1.2.3.4-1 describes how IMS session hold and resume is performed via II interface for ICS UE. 

ICS UE A MSC Server 



MGCF 



MGW 



S-CSCF 



sec AS 



UE B 



ICS UE A has an ongoing session with UE B. 



■1.l1:hold- 



2. Completion of session hold between ICS UE A & UE B 



-3. 11: resume- 



4. Completion of session resume between ICS UE A & UE B 



Figure 7. 6.1.2.3.4-1: IMS communication Hold and Resume by ICS UE 

1. The ICS UE A sends a Hold message to the SCC AS via II reference point. 

2. The session between ICS UE A and UE B is held as specified in clause 7.6.1.2.2.4. 

3. The ICS UE A sends a Resume message to the SCC AS via II reference point. 

4. The session between ICS UE A and UE B is resumed as specified in clause 7.6.1.2.2.4. 

7.6.1 .2.3.5 Explicit Communication Transfer 

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Explicit 
Communication Transfer. 



7.6.1.2.3.5.1 



Consultative Explicit Communication Transfer 



Figure 7. 6.1.2.3.5.1-1 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer 
initiator using II interface. The ICS UE A has a held call with UE B and an ongoing call with UE C before transfer. 



ICS UE A 



MGCF 



UE C 



ICS UE A has an ongoing call with UE C. ICS UE A holds the call with UE B. 



-1. 11: refer B to C- 



2. Refer B to C 



-3. 11: transfer complete- 



4. Session release between A & B 



Figure 7. 6.1.2.3.5.1-1 : IMS Consultative ECT via II for ICS UE (transfer initiator) 

1. The ICS UE A initiates transfer of UE B to UE C by sending a transfer message to SCC AS using II interface. 

2. Completion of referring UE B to UE C as specified in TS 24.173 [8] and releasing the session between the ICS 

UE A and UE C. 

3. The SCC AS sends the transfer complete message to ICS UE A via II interface. 
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4. The ICS UE A releases the calls between it and UE B. 

Figure 7.6.1.2.3.5.1-2 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer 
recipient using II interface. The UE A has a held call with UE C and also has a held call with ICS UE B before transfer. 
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UE A puts UE B on hold; UE A puts UE C on hold 
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5. Refer B to C and session release between C & A 



-6. II: transfer complete- 



7. Notify (transfer_ 
complete) 



- 8. Notify (transfer complete)- 



9. Session release between A & B 



Figure 7.6.1.2.3.5.1-2: IMS Consultative ECT via II for ICS UE (transfer recipient) 

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER request as specified in TS 24.173 [8]. 

2. The S-CSCF sends the REFER to the SCC AS as it was inserted at session establishment. 

3. The S-CSCF sends a transfer message to the ICS UE B via II interface. 

4. The ISC UE B initiates a call initiation message to SCC AS via II interface. 

5. Completion of referring the ICS UE B to UE C as specified in TS 24.173 [8] and releasing the session between 

the UE A and UE C. 

6. The ICS UE B provides an indication that the communication transfer is complete to SCC AS via II interface. 

7. The SCC AS sends a NOTIFY message to the S-CSCF. 

8. The NOTIFY is sent to UE A. 

9. The UE A initiates session release with ICS UE B and release the session. 



7.6.1.2.3.5.2 



Blind Explicit Communication Transfer 



Figure 7. 6.1.2.3.5.2-1 describes how IMS Blind ECT is performed when ICS UE is playing the role of transfer initiator 
using II interface. The ICS UE A has a held call with UE B and an ongoing call with UE C before transfer. 
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ICS UE A holds the call with UE B. no session between ICS UE A and UE C. 
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3. II: transfer complete- 



Figure 7. 6.1.2.3.5.2-1 : IMS Blind ECT via II for ICS UE (transfer initiator) 
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1. The ICS UE A initiates transfer of UE B to UE C by sending a transfer message to SCC AS using II interface. 

2. Completion of referring UE B to UE C as specified in TS 24.173 [8] and releasing the session between the ICS 

UEAandUEB. 

3. The SCC AS sends the transfer complete message to ICS UE A via II interface. 

Figure 7.6.1.2.3.5.2-2 describes how IMS blind ECT is performed when ICS UE is playing the role of transfer recipient 
using II interface. The UE A has a held call with UE C and an ongoing call with ICS UE B before transfer. 



ICS UE B 



MSC 



MGCF 



MGW 



S-CSCF 



SCC AS 



UE A 



UE C 



session between ICS UE B & UE A on hold, no session between UE B & UE C 



-3. 11: refer B to C- 



-1 . Refer (B to C)- 



2. Refer (B to C)- 



4. session released between B & C 



-5. 11: call initiation to C- 



6. completion of establishing the session between B & C 



■7. II : transfer complete- 



. Notify (transfer_ 
complete) 



- 9. Notify (transfer complete)- 



Figure 7.6.1.2.3.5.2-2: IMS Blind ECT via 11 for ICS UE (transfer recipient) 

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER request as specified in TS 24.173 [8]. 

2. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabUshment. 

3. The S-CSCF sends a transfer message to the ICS UE B via II interface. 

4. Session between UE A and ICS UE B is released as specified in clause 7.6.1.2.2.5.2. 

5. The ISC UE B initiates session establishment towards UE C by initiating a call initiation message to SCC AS via 

II interface. 

6. A session is established between the ICS UE B and UE C as specified in clause 7.6.1.2.2.5.2. 

7. The ICS UE B provides indication that the communication transfer is complete to SCC AS via II interface. 

8. The SCC AS sends a NOTIFY message to the S-CSCF. 

9. The NOTIFY is sent to UE A. 



7.6.1.2.3.6 



Conferencing 



IMS procedures as defined in TS 24.173 [8] apply The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Conferencing. 

Figure 7.6.1.2.3.6-1 describes how ICS UE executes the IMS conferencing when using II interface. The ICS UE A has 
a held call with UE B and an ongoing call with UE C before it initiates a conference. 
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Figure 7.6.1.2.3.6-1 : ICS UE executes the IMS Conferencing via II 

1 . The ICS UE A initiates a session with the conference AS by sending a conference invitation message to SCC AS 

via II interface. 

2. A session is estabHshed between the ICS UE A and conference AS as specified in clause 7.6.1.2.2.6. 

3. The ICS UE A initiates a message to the SCC AS via II interface indicating UE B transferring the current session 

to the conference AS. 

4. UE B is referred to the conference AS as specified in clause 7.6.1.2.2.6. 

5. The SCC AS sends a transfer completed message to ICS UE A via II interface. 

6. The session between the ICS UE A and UE B is released. 

7. Step 3-5 is repeated for UE C. 

8. The session between the ICS UE A and UE C is released. 

NOTE: As specified in TS 24. 147 [21], another alternative for this scenario is that ICS UE sends Party B and C 
number to conference AS via SCC AS. Consequently conference AS invites Party B and C to the 
conference. 



7.6.1.2.3.7 



Communication Waiting 



IMS procedures as defined in TS 24.173 [8] apply The SCC AS combines the description of the CS bearer with the 
service control signalling communicated over the II reference point, as specified in clause 7.1 of this document. 

7.6.1 .2.4 When use of Gm or 11 reference point is not possible due to VPLIVIN limitations 

7.6.1 .2.4.1 When attached to an MSC Server enhanced with ICS 
Procedures specified in clause 7.6.2 Service Consistency for non ICS UE apply. 

7.6.1 .2.4.2 When attached to an MSC Server not enhanced with ICS 
Procedures specified in clause 7.6.3 apply. 
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7.6.1 .3 User configuration of Supplementary Services 

The Ut reference point over IP-CAN shall be used to manage the IMS multimedia telephony communication service 
settings data as specified in TS 24.173 [8]. II does not support configuration of supplementary services. 

7.6.2 Supplementary service invocation using the MSC Server enhanced 
for ICS 

7.6.2.1 Overview 

For IMS sessions established by non ICS UEs using the MSC Server enhanced for ICS, the 12 reference point is used 
for communication of service control signalling. The MSC Server enhanced for ICS shall perform the necessary 
interworking between the 12 reference point and CS signalling to allow the IMS to provide the IMS Multimedia 
Telephony Service as defined in TS 22.173 [4]. 

7.6.2.2 Line ID Services (OIP, OIR, TIP, TIR) 

For IMS sessions established by UEs using the 12 reference point, the MSC Server enhanced for ICS shall perform the 
necessary interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.081 [13]) to allow 
DIP, OIR, TIP and TIR as described in TS 24.173 [8] to be controlled by the IMS. 

For OIP, the MSC Server may interwork any display name received in conjunction with the TEL URI or SIP URI to the 
CS signalling specified for the calling name presentation (CNAP) service (e.g. as described in TS 24.096 [29]). 

NOTE 1 : The ability to interwork identity information from the 12 reference point to CS signalling is limited to 

scenarios where the IMS identity is a TEL URI or its SIP URI equivalent as described in TS 23.228 [2] or 
to where a display name is received and the MSC Server supports the interworking described in this 
clause 

NOTE 2: A terminating UE using CS signalling is not able to temporarily override default settings for the TIP/TIR 
supplementary service. 

NOTE 3: Interworking of display name received in conjunction with a Tel URI or SIP URI to calling name 

presentation using CNAP is subject to local regulatory requirements on calling line identity and whether 
the originating network of the call is trusted to provide an authentic identity. 



7.6.2.3 Communication Diversion Services 

For IMS sessions established by UEs using the 12 reference point, the MSC Server enhanced for ICS shall perform the 
necessary interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.082 [14]) to allow 
Communication Diversion (CDIV) services to be executed in the IMS. 

7.6.2.3.1 Communication Forwarding Unconditional (CFU) 

Communication Forwarding Unconditional (CFU) is provided as specified in TS 24.173 [8]. 

7.6.2.3.2 Communication Forwarding Busy (CFB) 

Communication Forwarding network determined user Busy (CFB) is provided as specified in TS 24.173 [8]. 

For Communication Forwarding user determined Busy (CFB), the MSC Server enhanced for ICS shall perform the 
necessary interworking between CS signalling (e.g. as described in TS 24.082 [14]) and the 12 reference point to allow 
the IMS to execute CFB. 

7.6.2.3.3 Communication Forwarding No Reply (CFNR) 

Communication Forwarding No Reply (CFNR) is provided as specified in TS 24.173 [8]. 
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The MSC Server enhanced for ICS shall allow the IMS to control the length of time allowed for the UE to reply to the 
communication request prior to invoking CFNR. 

7.6.2.3.4 Communication Forwarding on Not Logged-in (CFNL) 

Communication Forwarding on Not Logged-in (CFNL) is provided as specified in TS 24.173 [8]. 

7.6.2.3.5 Communication Deflection (CD) 

For Communication Deflection (CD), the MSC Server enhanced for ICS shall perform the necessary interworking 
between CS signalling (e.g. as described in TS 24.072 [15]) and the 12 reference point to allow the UE to deflect an 
incoming call back to the IMS for redirection to another user. 

7.6.2.3.6 Communication Forwarding on Subscriber Not Reachable (CFNRc) 

For Communication Forwarding on Subscriber Not Reachable (CFNRc), the MSC Server enhanced for ICS shall return 
the appropriate reply to the offered session to allow the IMS to execute CFNRc, (e.g. as specified in TS 24.604 [26]). 

7.6.2.3.7 Communication Diversion Notification (CDIVN) 

The support of interworking between CS signalling and the IMS for the CDIVN service is not supported at the MSC 
Server enhanced for ICS. 

7.6.2.3.8 Diversion notifications to originating users 

For IMS sessions originated by UEs using the 12 reference point, the MSC Server enhanced for ICS shall perform the 
necessary interworking between the 12 reference point and CS signalling described in TS 24.082 [14] and 
TS 24.072 [15] to allow the UE to receive notification that an origination was diverted, for use in networks which 
support this subscription option. This is applicable to all CDIV services. 

NOTE: Direct mapping between IMS diversion conditions and CS domain supplementary service codes might not 
be possible for all services (e.g. CFNL). 

7.6.2.4 Connnnunication Barring 

For IMS sessions established by UEs using the 12 reference point, the MSC Server enhanced for ICS shall perform the 
necessary interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.088 [16]) to 
provide the UE with notification that a Communications Barring (CB) service was invoked. 

NOTE: Unique mappings between SIP responses defined in TS 24.61 1 [28] and CS domain supplementary 
service codes are not possible for OCB and ICB. 

7.6.2.5 Gonnnnunication Hold/Resunne 

For IMS sessions established by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary 
interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.083 [18]) to allow 
communication hold and resume to be controlled by the IMS. 

Figure 7.6.2.5-1 describes how IMS communication hold and resume is performed via the MSC Server enhanced for 
ICS. 
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Figure 7.6.2.5-1 : IMS Communication Hold and Resume via MSC Server enhanced for ICS 

1. UE A sends a Hold message to the CS network (e.g. as specified in TS 24.083 [18]). 

2. The MSC Server initiates interaction with the the CS-MGW over the Mc reference point instructing it to stop 
sending the media stream toward UE B but to keep the resources for the session reserved. 

3. The MSC Server sends the Hold message to the S-CSCF indicating the session is being put on hold as described 
in TS 24.173 [8]. 

NOTE 1 : For point-to-point speech-only sessions, the SDP offer in the Hold message shall also include RTCP 

bandwidth modifiers with values greater than zero to allow the remote end to detect that the link is alive 
during hold, as specified in sub-clause 7.3.1 of TS 26.114 [17]. 

4. The S-CSCF sends the Hold message to the SCC AS as it was inserted at session establishment. 

5. The SCC AS sends the Hold message to the S-CSCF. 

6. The Hold message is forwarded to UE B. 

7. UE A sends a Retrieve message on the CS network (e.g. as specified in TS 24.083 [18]). 

8. The MSC Server initiates interaction with the CS-MGW over the Mc reference point instructing it to resume 
sending the media stream toward UE B. 

9. The MSC Server sends a Resume message to the S-CSCF indicating the session is being resumed as described in 
TS 24.173 [8]. 

NOTE 2: For point-to-point speech-only sessions, the SDP offer in the Resume message may also include RTCP 
bandwidth modifiers with values equal to zero to turn off RTCP as specified in sub-clause 7.3.1 of 
TS 26.114 [17]. 

10. The S-CSCF sends the Resume message to the SCC AS. 

1 1. The SCC AS sends the Resume message to the S-CSCF. 
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12. The Resume message is forwarded to UE B. 



7.6.2.6 



Communication Waiting 



For IMS sessions established by UEs using the 12 reference point, the MSC Server enhanced for ICS shall perform the 
necessary interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.083 [18]) to allow 
Communication Waiting (CW) to be controlled by the IMS. 

Figure 7.6.2.6-1 describes how IMS CW is performed via the MSC Server enhanced for ICS. 
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Figure 7.6.2.6-1 : IMS Communication Waiting via MSC Server enhanced for ICS 

1 . An incoming INVITE is received at the S-CSCF of UE A. 

2. Filter criteria direct the S-CSCF to send the INVITE to the SCC AS. 

3. The SCC AS sends the INVITE to the S-CSCF. 

4. The S-CSCF forwards the INVITE to the MSC Server based on the contact address stored during registration. 

5. The MSC Server sends a Setup message to UE A to inform it of the waiting call (e.g. as specified in 
TS 24.083 [18]). 

6. UE A sends an Alerting message for the waiting call. 

7. The MSC Server sends an indication that the call is waiting. 

8. The S-CSCF forwards the indication that the call is waiting to the SCC AS. 

9. The SCC AS forwards the indication that the call is waiting to the S-CSCF. 
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10. The S-CSCF forwards the indication that the call is waiting to UE C. 

1 1 . The ICS User accepts the call and UE A sends a Hold message to put the existing session on hold. 

12. The existing session between the MSC Server and UE B is put on hold as described in clause 7.6.2.5 of this 
specification. 

13. UE A sends a Connect message for the waiting call. 

14. Completion of the IMS session setup procedures. 

7.6.2.7 Explicit Communication Transfer 

For IMS sessions established by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary 
interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.091 [19]) to allow Explicit 
Communication Transfer (ECT) to be controlled by the IMS. 

When the UE initiates ECT via CS access, the MSC Server enhanced for ICS shall support consultative transfer and 
shall play the initiator role as described in TS 23.228 [2] on behalf of the UE. The MSC Server enhanced for ICS shall 
also support the recipient and target roles on behalf of the UE for consultative transfer as described in TS.23.228 [2]. 

The MSC Server enhanced for ICS shall support the recipient and target roles on behalf of the UE for blind transfer as 
described in TS 23.228 [2]. 

The MSC Server enhanced for ICS shall support the recipient and target roles on behalf of the UE for assured transfer 
as described in TS 23.228 [2]. 

Figure 7.6.2.7-1 describes how IMS consultative ECT is performed via CS access, with the MSC Server enhanced for 
ICS playing the role of transfer initiator on behalf of the UE. 
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Figure 7.6.2.7-1 : IMS Consultative ECT via MSC Server enhanced for ICS (transfer initiator) 

1. UE A initiates transfer of UE B to UE C by sending a call transfer message (e.g. as specified in TS 24.091 [19]). 

2. The MSC Server sends a REFER to the S-CSCF. The REFER indicates that UE B is to be transferred to UE C 
and that this new session is to replace the current session between UE A and UE B. 

3. The S-CSCF sends the REFER to the SCC AS as it was inserted at session establishment. 

4. The SCC AS sends the REFER to the S-CSCF. 

5. The S-CSCF sends the REFER to the TAS for service execution. 

6. The TAS sends the REFER to the S-CSCF. 

7. The REFER is sent to UE B as the transfer recipient. 

8. UE B initiates session establishment with UE C as specified in TS 24.173 [8]. 

9. UE C initiates session release with UE A as specified in TS 24.173 [8]. 

10. UE B provides indication that the communication transfer is complete as specified in TS 24.173 [8]. 

1 1. The S-CSCF sends the NOTIFY to the TAS. 

12. The TAS sends the NOTIFY to the S-CSCF. 

13. The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment. 

14. The SCC AS sends the NOTIFY to the S-CSCF. 
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15. The MSC Server, as transfer initiator, receives notification that communication transfer is complete. 

16. The MSC Server releases the calls (A-B and A-C) toward UE A and indicates transfer success as specified in 
TS 24.091 [19]. 

17. The MSC Server, as transfer initiator, initiates release of the IMS session with UE B. 

Figure 7.6.2.7-2 describes how IMS consultative ECT is performed via CS access, with the MSC Server enhanced for 
ICS playing the role of transfer recipient on behalf of the UE. 
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Figure 7.6.2.7-2: IMS Consultative ECT via MSC Server enhanced for ICS (transfer recipient) 

1 . UE A initiates transfer of UE B to UE C by sending a REFER as specified in TS 24. 173 [8] . 

2. The S-CSCF sends the REFER to the TAS for service execution. 

3. The TAS sends the REFER to the S-CSCF. 

4. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabHshment. 

5. The SCC AS sends the REFER to the S-CSCF within the dialog created for the session between UE A and UE 
B. 

6. The REFER is sent to the MSC Server as the transfer recipient. 

7. On behalf of UE B, the MSC Server initiates session establishment towards UE C. 

8. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS. 
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9. The sec AS sends the INVITE to the S-CSCF. 

10. The S-CSCF sends the INVITE to the TAS. 

1 1. The TAS sends the INVITE to the S-CSCF. 

12. The S-CSCF continues with originated session processing as specified in TS 23.228 [2] and routes the request 
onwards to UE C. 

13. A session is estabHshed between the MSC Server (on behalf of UE B) and UE C. 

14. UE C initiates session release with UE A as specified in TS 24.173 [8]. 

15. The MSC Server provides indication that the communication transfer is complete by sending a NOTIFY. 
16 The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment. 

17. The SCC AS sends the NOTIFY to the S-CSCF. 

18. The S-CSCF sends the NOTIFY to the TAS. 

19. The TAS sends the NOTIFY to the S-CSCF. 

20. The NOTIFY is sent to UE A as specified in TS 24.173 [8]. 

21. The MSC Servers sends a message with notification of ECT invocation to UE B (e.g. as specified in 
TS 24.091 [19]). 

22. UE A initiates session release with the MSC Server as specified in TS 24.173 [8]. 

Figure 7.6.2.7-3 describes how IMS blind ECT is performed via CS access, with the MSC Server enhanced for ICS 
playing the role of transfer recipient on behalf of the UE. 
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Figure 7.6.2.7-3: IMS Blind ECT via MSC Server enhanced for ICS (transfer recipient) 

1. UE A initiates transfer of UE B to UE C by sending a REFER as specified in 3GPP 24.173 [8]. 

2. The S-CSCF sends the REFER to the TAS for service execution. 

3. The TAS sends the REFER to the S-CSCF. 

4. The S-CSCF sends the REFER to the SCC AS as it was inserted at session estabHshment. 

5. The SCC AS sends the REFER to the S-CSCF within the dialog created for the session between UE A and UE 
B. 

6. The REFER is sent to the MSC Server as the transfer recipient. 

7. UE A initiates release of the existing session with the MSC Server which is acting on behalf of UE B. 

8. On behalf of UE B, the MSC Server initiates session establishment towards UE C. 

9. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS. 

10. The SCC AS sends the INVITE to the S-CSCF. 

1 1. The S-CSCF sends the INVITE to the TAS. 

12. The TAS sends the INVITE to the S-CSCF. 

13. The S-CSCF continues with originated session processing as specified in TS 23.228 [2] and routes the request 
onwards to UE C. 
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14. A session is established between the MSC Server (on behalf of UE B) and UE C. 

15. The MSC Server sends a NOTIFY to provide indication that the communication transfer is complete. 

16. The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment. 

17. The SCC AS sends the NOTIFY to the S-CSCF. 

18. The S-CSCF sends the NOTIFY to the TAS. 

19. The TAS sends the NOTIFY to the S-CSCF. 

20. The NOTIFY is sent to UE A. 

21. The MSC Servers sends a message with notification of ECT invocation to UE B (e.g. as specified in 
TS 24.091 [19]). 

7.6.2.8 Conferencing 

For IMS sessions estabHshed by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary 
interworking between the 12 reference point and CS signalling (e.g. as described in TS 24.084 [20]) to allow 
Conferencing to be controlled by the IMS. 

When the UE initiates three-way session creation via CS access, the MSC Server enhanced for ICS shall support the 
initiator role as described in TS 23.228 [2] on behalf of the UE. The MSC Server enhanced for ICS shall be able to 
derive a conference factory URI, e.g. using components from the subscriber" s identity (e.g. IMSI). 

Once a conference is created, the MSC Server enhanced for ICS shall supporting adding parties to or removing parties 
from the conference on behalf of the UE. 

The MSC Server enhanced for ICS shall also support joining a conference on behalf of the UE upon receiving an 
invitation from a remote party or conference focus. 

If the conference is being managed by a UE using CS media, the MSC Server enhanced for ICS shall not allow the UE 
to create a private conversation with a remote party by splitting that party from the conference. 

NOTE: Interworking is blocked due to no multiparty split service being defined for MMTel. 

The MSC Server shall not subscribe to the conference related events in IMS.Figure 7.6.2.8-1 describes how conference 
creation can be performed via CS access, with the MSC Server enhanced for ICS playing the role of conference initiator 
on behalf of the UE. This flow does not preclude the use of other mechanisms for inviting remote parties to the 
conference as specified in TS 24.147 [21]. 
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Figure 7.6.2.8-1 : IMS Conferecing via MSC Server enhanced for ICS (initiator) 

1. UE A initiates creation of the conference by sending a multiparty call setup message (e.g. Build MPTY message 
as specified in TS 24.084 [20]). 

2. The MSC Server derives a conference factory URI and sends an INVITE to the S-CSCF. 

3. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS. 

4. The SCC AS sends the INVITE to the S-CSCF. 

5. The S-CSCF sends the INVITE to the Conferencing AS / MRFC. 

6. The Conferencing AS / MRFC creates a conference connection as specified in TS 24.147 [21]. 

7. The Conferencing AS / MRFC returns the conference URI to the S-CSCF. 

8. The S-CSCF sends the response to the SCC AS. 

9. The SCC AS sends the response to the S-CSCF. 

10. The S-CSCF sends the response to the MSC Server. 

1 1. The MSC Server sends a REFER to UE B to refer that party to the conference. 

12. The S-CSCF sends the REFER to the SCC AS as it was inserted at session establishment. 

13. The SCC AS sends the REFER to the S-CSCF. 

14. The S-CSCF sends the REFER to UE B. 
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15. UE B joins the conference as specified in TS 24.147 [21]. 

16. UE B sends a NOTIFY indicating transfer to the conference is complete. 

17. The S-CSCF sends the NOTIFY to the SCC AS. 

18. The SCC AS sends the NOTIFY to the S-CSCF. 

19. The S-CSCF sends the NOTIFY to the MSC Server. 

20. Steps 1 1 through 19 are repeated for UE C. 

NOTE: UE B and UE C can be referred to the conference in parallel. 

21. The MSC Server sends an acknowledgement to UE A (e.g. Build MPTY Acknowledgement as specified in 
TS 24.084 [20]). 

7.6.2.9 User configuration of Supplementary Services 

7.6.2.9.1 UE not supporting multimedia telephony 

The MSC Server enhanced for ICS may implement a communication service setting conversion function between CS 
signalling (e.g., as described in TS 24.010 [30]) and communication service setting procedures (e.g. as defined in 
TS 24.173 [8]). 

The TAS may be provisioned with an optional flag. The TAS shall perform the following: 

- If the flag is set to true, the TAS shall allow communication service setting procedures coming from the MSC 
Server enhanced for ICS. The flag shall not be set to true when the operator supports direct Ut from the UE 

- If the flag is set to false, the TAS shall not allow communication service setting conversion procedures coming 
from the MSC Server enhanced for ICS. 

7.6.2.9.2 UE supporting multimedia telephony 

Clause 7.6.1.3 applies. 

7.6.3 Service consistency for non ICS UE when attached to an MSC 
Server not enhanced with ICS 

7.6.3.1 Line ID Services (OIP, OIR, TIP, TIR) 

The service control for the Line ID services may be provided by the CS domain if they are provisioned in the CS 
domain. 

7.6.3.2 Comnnunication Diversion Services 

7.6.3.2.1 Communication Diversion services; CPU, CFNL 

Standard IMS procedures apply with the lUA of the SCC AS presenting the SIP UA behaviour toward IMS on behalf of 
the ICS UE. 

7.6.3.2.2 Communication Diversion services; CFNR, CFB 

IMS control of these services are provided with the lUA of the SCC AS presenting the SIP UA behaviour toward IMS 
on behalf of the ICS UE. 

NOTE: Annex D describes several implementation options which may used for the execution of these services 
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7.6.3.2.3 Communication Diversion services; Communication Deflection 

The service control for the Call Deflection service may be provided by the CS domain if it is provisioned in the CS 
domain. 

NOTE: Annex C describes an implementation option which may be used alternatively for the execution of this 
service in IMS. 

7.6.3.3 Gonnnnunication Barring 

Standard IMS procedures apply with the lUA of the SCC AS presenting the SIP UA behaviour toward IMS on behalf of 
the ICS UE. 

7.6.3.4 Connnnunication Hold/Resunne 

The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned 
in the CS domain. 

7.6.3.5 Explicit Connnnunication Transfer 

The service control for the Explicit Call Transfer service may be provided by the CS domain if it is provisioned in the 
CS domain. 

7.6.3.6 Conferencing 

The service control for the Multiparty service may be provided by the CS domain if it is provisioned in the CS domain. 

7.6.3.7 User configuration of Supplennentary Services 

7.7 Session Release 

7.7.1 Session Release for ICS UE 

7.7.1 .1 General Gnn Procedures 

If receiving a session release from the CS access leg for the ICS UE using Gm while the PS access leg is still active, the 
SCC AS shall release the CS access leg. The SCC AS shall further update the remote leg, and if applicable, the PS 
access leg, to reflect the change of media. 

NOTE: Race conditions may occur where the session release of the CS access leg could arrive prior an update 
over Gm from the UE removing the CS media. 

7.7.1 .2 Session Release for Gnn and II 

Figure 7.7.1.2-1 provides a call flow illustrating the session release procedures for an ICS UE attached to an MSC 
Server enhanced for ICS, which has an ICS session already established. This call flow applies when either Gm or II 
have been used to set up the Service Control Signalling Path. 
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Figure 7.7.1.2-1 : Session Release for Gm and II when using an MSC server enhanced for ICS 

1 . IMS procedures are executed for the release of the service control signalling session when using the Gm 
reference point as defined in clause 5.10 of TS 23.228 [2]. When using II, the procedure for the release of the 
service control signalling session is documented in clause 7.7.1.2. 

2. The sec AS initiates release of the CS Bearer Control Signalling Path.towards the ICS UE. 

Alternatively the ICS UE may initiate release of the CS Bearer Control SignalHng Path. The SCC AS and the ICS 
UE shall gracefully handle the case when both the SCC AS and ICS UE initiate the release procedure. 

The call flow in Figure 7.7.1.2-1 also applies when the ICS UE is attached to an MSC server . 



7.7.1.3 



Release of the Service Control Signalling Session when using 11 



7.7.1.3.1 



ICS UE Initiated Release 



Figure 7.7.1.3.1-1 provides a call flow illustrating the release of the service control signalling session by an ICS UE 
regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using II. 
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Figure 7.7.1.3.1-1 : ICS UE initiated release of the service control signalling session over II 
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1 . The ICS UE sends a release over II . 

2 The sec AS sends a SIP BYE to the I/S-CSCF serving the ICS UE. 

3. The S-CSCF forward the SIP BYE to UE A. 

4-5. UE-B sends a SIP OK to the SCC AS via the S-CSCF of the UE A. 

6. The SCC AS completes the session release procedure by sending a release-ack over II. 

NOTE: If this is the release of the last service control signalling session, then the CS Bearer Control Signalling 
Path is released as described in Clause 7.7.1.2 



7.7.1.3.2 



Network Initiated Release 



Figure 7.7.1.3.2-1 provides a call flow illustrating the release of a service control signalling session by the home IMS 
network regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using II. 
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Figure 7.7.1.3.2-1 : Network initiated release of a service control signalling session initiated using II 

1. The S-CSCF decides the session should be terminated due to administrative reasons or due to service expiration. 
Steps 2-5 occur in parallel to Steps 6-7. 

2. The S-CSCF sends a SIP BYE message to the SCC AS. 

3. The SCC AS sends a release message over II to the ICS UE. 

4. The ICS UE sends a release-ack to the SCC AS over II. 

5. The SCC AS sends a SIP OK to the I/S-CSCF. 

6. The S-CSCF sends a SIP BYE message to UE A. 

7. UE-A acknowledges receipt of the SIP BYE and sends a SIP OK back to the S-CSCF. 

NOTE: If this is the release of the last service control signalling session, then the CS Bearer Control Signalling 
Path is released as described in Clause 7.7.1.2 
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7.7.1.3.3 



Far End Initiated Release 



Figure 7.7.1.3.3-1 provides a call flow illustrating the release of a service control signalling session by the far end 
regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using II. 
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Figure 7.7.1.3.3-1: Far End release of a service control signalling session initiated using 11 

1. UE A terminates the session by sending a SIP BYE (via its own S-CSCF) towards the I/S-CSCF of ICS UE B. 

2. The S-CSCF sends a SIP BYE message to the SCC AS. 

3. The SCC AS sends a release message over II to the ICS UE. 

4. The ICS UE sends a release-ack to the SCC AS over II . 

5. The SCC AS sends a SIP OK to the I/S-CSCF. 

6. The S-CSCF sends a SIP OK message to UE A. 

NOTE: If this is the release of the last service control signalling session, then the CS Bearer Control Signalling 
Path is released as described in Clause 7.7.1.2 



7.8 Loss of Gm capability 



The Figure 7.8-1 provides an example flow for transfer of Session Control Signalling Path from Gm to II when the UE 
discovers Gm is not available and UE supports II.. 
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Figure 7.8-1 : Service Control Signalling Path handover from Gm to II 

1 . Upon detecting that the Gm reference point is not possible after, ICS UE triggers the service control signalling 
path handover. 

2. ICS UE sends the service control signalling path handover notification to the SCC AS requesting a switch to II 
for Service Control Signalling Path. 

3. SCC AS accepts the handover request, and returns the acknowledgement to ICS UE over II. 

After the above steps, the Service Control Signalling Path is switched from the Gm reference point to the II reference 
point. 



8 Charging 

8.1 General description 

The charging strategy applied in ICS shall ensure complete and correct charging of the access leg that is used for an ICS 
call. An ICS subscriber may establish or accept a call through CS access or through an IP access network (IP-CAN). 
The charge that is levied against an ICS subscriber for a call shall encompass the usage of the access network (CS 
access or IP-CAN) as well as the usage of the IMS network, further depending on the destination of the call and other 
call related aspects. The access related charge for an ICS call, i.e. the CS access network related charge or IP-CAN 
related charge, shall be included in charging record generated by SCC AS. 

The charge of a SIP call or session may be adapted when this call or session is subject to a value added service (e.g. 
number translation, call diversion) or is subject to a supplementary service (e.g. call forwarding, call transfer, 
conference call). 



8.2 Offline charging 



Charging record generated by the SCC AS may be correlated with charging records generated in the MSC Server or 
with charging records in the IP-CAN, where applicable. The combination of charging records from SCC AS with 
charging records from MSC Server or IP-CAN is used for determining access charge for the call or multimedia session. 
The combination of these charging records may further be correlated with other IMS -based charging records generated 
by S-CSCF or other functional entities in the IMS network, for the purpose of generating an overall charge for a call or 
multimedia session, including access related charge. 
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8.3 On-line charging 



When on-line charging is appHed for an ICS subscriber, this on-Hne charging should be performed strictly in IMS. CS 
network based on-line charging service (e.g., CAMEL prepaid), for example, shall not be invoked for ICS subscribers. 

NOTE: If for an ICS subscriber a call that is established in CS is not anchored in IMS network, i.e. no ICS is 
applied for that call, then on-line charging in CS access can be applied for that call. 
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Annex A (informative): 
Service Consistency 



IMS Centralized Services (ICS) provides communication services such that all services, and service control, are based 
on IMS mechanisms and enablers. It enables IMS services when using CS access for the media bearer. 

With ICS, the user services are provided by IMS. User sessions are controlled in IMS via PS or CS access. When using 
CS access network, or when using PS access networks which do not support full duplex speech component of an IMS 
service, the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions. 

Functionality is needed to provide IMS Centralized Services to devices using a circuit switched access network for 
media transport. Two fundamentally different approaches are enabled in this specification. One approach supports 
legacy UEs by placing new functional elements in the MSC Server. Another approach provides new functionality in the 
UE. The following figure depicts the provision of IMS Centralized Services for these approaches from the user"s 
perspective. This figure is intended to be illustrative in nature, and is not intended to depict a complete or definitive 
identification of the various IMS Centralized Services that may be provided using different access networks or 
solutions. 
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Figure A-1 : IMS Centralized Services 
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Annex B (informative): 

ICS functions in different deployment scenarios 

The following tables provides guidance on which of the functions and functionalities are needed in the different 
deployment scenarios. 

Scenario 1: An operator who only supports UEs that have ICS functionality for their ICS Users: 





MSC Server 
with ICS 
enliancements 


ICSUE 


Transparent controi 
cliannei 


sec AS 


11 


Gm 


CAA 


lUA 


T-ADS 


Required 


No 


Yes 


As driven 

by 

operator 

policy and 

VPLMN 

support. 


As driven 

by 

operator 

policy and 

VPLMN 

support. 


Yes, only 
if 11 is 
supported 


Yes 


Yes 



ICS Users using a non-ICS UE (e.g. after SIM swap) will not make use of the transparent control channel; non ICS UE 
originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. 
TS 24.008) for call origination. 

Scenario 2: An operator who only supports non ICS UEs for their ICS Users: 





MSC Server 
witli ICS 
enhiancements 


ICSUE 


Transparent 
control channel 


sec AS 


11 


Gm 


CAA 


lUA 


T-ADS 


Required 


Yes 


No 


No 


No 


No 


Conditional* 


Yes 



* Required if the operator supports IN (e.g. CAMEL) redirection of CS originated calls. 

Scenario 3: An operator who supports UE"s for their ICS Users that do, and do not, have ICS functionality (to different 
subscribers and the same subscribers) ensuring the coexistence of UEs that have and do not have ICS functionality: 





MSC Server 
with ICS 
enhancements 


ICSUE 


Transparent control 
channel 


sec AS 


11 


Gm 


CAA 


lUA 


T-ADS 


Required 


Yes 


Yes 


As driven 

by 

operator 

policy and 

VPLMN 

support. 


As driven 

by 

operator 

policy and 

VPLMN 

support. 


Yes, if 11 

is 

supported 


Yes 


Yes 
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Scenario 4: Inbound roaming - operator supports ICS 

Inbound roaming subscribers on an operator's network that supports either the same or different ICS functionaUty that 
the inbound roaming subscriber is using, ensuring the coexistence of UEs that have and do not have ICS functionality. 

Sub case 4.1: Subscriber from operator supporting scenario 1 roams into network of scenario 1 

Same functions and functionalities in roaming in-network as in scenario 1. No additional functions or functionalities. 

Sub case 4.2: Subscriber from operator supporting scenario 2 roams into network of scenario 2 

Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities. 

Sub case 4.3: Subscriber from operator supporting scenario 1 roams into network of scenario 2 

Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities. 
Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control 
channel between ICS UE and SCC AS in the home network. 

ICS Users using a non-ICS UE (e.g. after SIM swap) will not make use of the transparent control channel; non ICS UE 
originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. 
TS 24.008) for call origination. 

Sub case 4.4: Subscriber from operator supporting scenario 2 roams into network of scenario 1 

Same functions and functionalities in roaming in-network as in scenario 1: No additional functions or functionalities. 
Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed 
to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008) for call 
origination. 

Scenario 5: Inbound roaming - operator does not support ICS 

Inbound roaming subscribers on an operator's network that does not support ICS. 

Sub case 5.1: Subscriber from operator supporting scenario 1 roams into an operator's network that does not support 
ICS. 

Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control 
channel between ICS UE and SCC AS in the home network. 

ICS Users using a non-ICS UE (e.g. after SIM swap) will not make use of the transparent control channel; non ICS UE 
originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. 
TS 24.008) for call origination. 

Sub case 5.2 Subscriber from operator supporting scenario 2 roams into an operator's network that does not support 
ICS. 

Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed 
to the home IMS using IN (e.g. CAMEL) signaling in conjunction with CS signalling (e.g. TS 24.008) for call 
origination. 
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Annex C (informative): 

Communication Deflection support when call has been 

delivered using CS call control 

When a call has been delivered to a non ICS UE using CS call control, Communication Deflection service can be 
centralized and executed in IMS by using IN (e.g. 0-CSI CAMEL) if it is supported by the network and user 
subscription. 
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Annex D (informative): 

Conditional Call Forwarding support when call has been 

delivered using CS call control 

When a call has been delivered to an ICS UE using CS call control, conditional call forwarding services can be 
centralized and executed in IMS by one of (or a combination of) the following implementation options. 

Solution 1: Default PSIs 

In this solution, Conditional CF is configured in IMS with default service configuration in the CS domain. The 
Conditional CF services are configured in the HLR. The different forwarded number can be set in HLR to indicate the 
type of CF. The VMSC redirects the call to IMS for appropriate handling of the service in IMS. 

Solution 2: MAP suppression-of-announcements 

In this solution. Conditional CF is configured and provisioned in IMS domain exclusively, according to IMS 
Centralized Service principle. It provides means to suppress the announcement in CS domain at the MSC for 
CFNR/CFB. MGCF provides the appropriate responses to TAS on behalf of the ICS user in CS domain. 

For support of CFNRy, the TAS starts a supervisory no-reply timer on receipt of Alerting from the called party. If the 
timer expires without receipt of the Connect from the called party, the TAS invokes the CFNRy service. 

Solution 3: IN 

In this solution. Conditional CF is configured in IMS with default service configuration in the CS domain so that the 
VMSC invokes the CF service in the CS domain upon detection of CF triggers. IN (e.g. 0-CSI CAMEL service) is 
configured in the HLR to redirect session control to IMS for processing of CF. 
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